We are using Kivy for a RPi based project.
We use the Kivy Settings mechanism for editing of data records. Our main problem is, that creating a new settings dialog (via add_json_panel) takes quite a long time (several seconds).
Note: We cannot pre create the dialogs, because we dynamically modify the dialogs fields.
Is there a way to speed this up?
What are the correct Kivy providers (text, image, window) for a RPi?
I think this is probably just outright slow - unfortunately the Settings widget is inflexible, outdated, and not up to modern Kivy standards. We've been discussing how to deprecate and replace it, but haven't taken action yet.
Depending on what you're doing, it may be simpler (and potentially much faster) to implement your own settings management widgets.
Related
I am seeking a way to allow my non-tech users to specify a workflow and execute it (if anyone is interested, I want them to specify and execute test cases). Visual programming seems a good way to go.
Can I modify the Scratch IDE to remove some categories (such as sound, motion, etc), and add some of my own? Ditto for individual keywords (obviously, I then need to handle new keywords).
I have Googled, but the answer is not immediately apparent.
[Update] I have just found Google's Blockly
Blockly was influenced by App Inventor, which in turn was influenced
by Scratch, which in turn was influenced by StarLogo.
It looks very promising. Especially when it says
Exportable code. Users can extract their programs as JavaScript, Python, PHP, Dart or other language so that when they outgrow Blockly
they can keep learning.
Open source. Everything about Blockly is open: you can fork it, hack it, and use it in your own websites.
Extensible. Make Blockly fit with your application by adding custom blocks for your API and remove unneeded blocks and
functionality.
One possible snag is that it is browser based, but if my management don't like that, then I can create a dummy Windows based app consisting of little but a TWebBrowser component.
I will investigate and report back - unless someone else posts an acceptable answer first.
The short answer to your initial question is: no. You can't customize Scratch, or not to the extent that you seem to ask/want.
That said, look at:
custom blocks.
scratch extensions.
variants like snap
using scratch's source code in squeak to make your own variant.
other systems inspired from scratch, like appinventor and blockly.
Only the first two are compatible with the scratch web site.
A word on the site: depending on your purpose with Scratch, the exchange between users is a powerful part of scratch. Check how cooperation is supported, like the backpack. There's also a good wiki that documents much of the above.
I typically work on web apps that will only be used by a small group of well-controlled people, but now find that I'm writing something that has the potential to be used by a very large population. This means that the design and "look" will be very important to the success.
While I can certainly code up something functional, it ain't gonna look pretty, so I know that I'll need to get an outside designer to make things look good. Never having worked that way before I had a few questions about the mechanics of how this happens and how to try to make things easier.
We do Java, so when building a rich interface, we use GWT. I know that when working with designers, they typically provide images of what the interface should look like without any type of "useable" output. My question is how best to bridge that gap between a simple drawing of an interface to a fully functional realized one.
Any thoughts are appreciated.
Well, "it depends", as always.
Nowadays, I don't think you can work wit someone who simply provides PhotoShop mockups. At least not at your level. Mockups are simply too static, and translating those mockups to actual pages that actually work with different browsers properly is a skill set all its own.
So, you need someone beyond simply a designer, especially if you are planning any javascript wizardry, animations, or other dynamic elements that don't capture at all well on a static image.
What you really want is an "operational" mockup. Static HTML files that look and behave as best as can be done to what the UI designer wants to do, including transitions, work flow, etc. This artifact can be run through all of the stake holders as a live mockup, letting folks "Feel" the site.
Once you have these HTML files, you can then do your part of backfilling these pages with actual server side content. Obviously you can start early working on models and working with the designers so as to have services ready to support the site functionality, but you shouldn't be committing any real time in to actual pages for the site.
As for interacting with the designers, I talk more about that over here: How can I make my JSP project easier for a designer to work with
I worked on a project very much like this. We had "comps" which were pictures of what the interface would look like. We identified common objects and build modules. Then built pages (this was for a web app) from modules plus any elements that were unique to that "comp".
A couple things to keep in mind that will make life much easier: use the comps/drawings as more of a recommendation rather than set in stone design. Try to identify common pieces early on and reuse code.
Also, designers aren't user experience gods. They often have a good idea of how things should work, but if you are close to your product and have a lot of product knowledge, don't be afraid to tweak the design as you and your group see fit. One thing that designers typically lack is product knowledge. They know a lot about general user experience and how a site should work, but they often won't know the in's and out's of your use cases and products.
If you are working with GWT, you should look for designers who are expert in CSS. Apart from, may be, the main layout of the website, all the application components like form fields, dialogs, tabs and grids etc. will need to be styled using CSS.
If the designers are not experienced in working with GWT, share the GWT's documentation about styling with them. It's a good idea to read these yourself as well. Specifically explore the GWT's theme-ing system.
Also try to make use of UiBinder as much as possible. This would allow you to stay as close to traditional HTML based design while still enjoying the GWT high level object oriented interfaces (both widgets and DOM).
Optionally you might want to tell the designers that GWT image bundles will automatically do "CSS Sprites" so they don't need to worry about page load performance issues related to images.
How easy it's to come up with a drag and drop web-based interface that'll provide me features to wire objects together, setup configurations nicely in a modal window for each object? I'm looking for links that've any similar kind of interface, or articles on this. also, i'm looking for your technology/language suggestions.
Another way I'm thinking - as a desktop appln + browser dependent addon..
Is it good to create such an user-interface using XUL, which can be deployed as an addon on Firefox/as a stand-alone application in Windows? Are there any other similar things/technologies which can provide a basic framework for us to build on it further?
Why do I need this, finally?
..for building simple Workflows, for defining process flows, that can provide me some auto-generated xml content which I can use for further processing.
Thanks!
I'm quite interested in this, too.
I've flirted with HTML5's DragDrop implementation - Quirksmode has Bad Things to say about that, so then I thought "Perhaps a JavaScript library can help me" - haven't checked out jquery for this yet, but I have checked out YUI's DragDrop, DragDropManager and DataSource, and its looking hopeful (consistent, reliable).
I tried things like adding an iframe on the fly to any document, to provide this kind of functionality without needing to add dependencies to the page given the iframe - mixed results, but in my case I was trying to cater for x-domain access, which proved difficult.
So I'd say JavaScript could be a winner - if designed poorly it could be difficult to manage resources though, if you want to potentially DragDrop/edit/config any element in a document - so watch out for that.
If you're keen and able, Adobe AIR apps also look promising - but I can't help with any more info on that, other than they're Desktop Apps with great flexibility.
I'ma going to keep an eye on your Question, I look forward to any other Answers/comments!
EDIT: I forgot to mention Flex (aka Flash Builder 4, latest version) is quite easy to create stuff like this, though I've had exposure to Flash for a while. It comes with the standard Adobe caveats; price, libraries, support.
Is there any reason to not write iphone apps without useing the interface builder?
(or in other words, is it ok to write apps without the builder?)
Personally, my applications use no NIBs within them, but that's more of a matter of how I started doing development than anything else. I transitioned over from doing Mac development (where I use Interface Builder almost every day) to iPhone from when the first beta SDKs were released. Initially, there was no Interface Builder, and even when it came you couldn't do a lot of things with it, so I never took the time to really get to know it on the iPhone. It's more a matter of me doing what I'm familiar with.
Jeff LaMarche makes a convincing argument in his article "Don't Fear the Interface Builder" for you to use Interface Builder wherever you can, and I encourage new developers to learn to use it first before dropping down to programmatic user interface generation. It saves you a tremendous amount of time for interfaces using standard elements.
Some people have argued that there is a performance benefit to be had using purely programmatic interfaces, but Matt Gallagher ran a series of benchmarks and found that this speedup is only typically on the order of 5-10%. If you really want to shave that last bit off of your application's startup time, you might be able to have the best of both worlds with Adrian Kosmaczewski's nib2objc, which generates Objective-C from your NIB files.
However, there are plenty of times that you'll need to manipulate interfaces programmatically, such as for custom views and animations. This code can exist in parallel with Interface Builder without too much confusion. Again, it's more of a matter of personal preference at this point, but my recommendation is to use Interface Builder due to the time it can save you.
I've never written an iPhone app that uses Interface Builder (.xib files), but that's just personal taste: I like applications to be 100% code.
The reason is that I don't like applications that require design-time tools if you need to change something later on. It creates a dependency that may not be a problem today or next month, but it can become a problem in 3 years time.
So, the answer is: yes, it's fine to write iPhone apps without using Interface Builder.
Sure, it's absolutely fine to write apps without IB. It takes a little bit more setup (I believe there are some modifications you have to make to your Info.plist file), but it's certainly possible, and people do it all the time.
Personally, I prefer using Interface Builder for most tasks, but usually just to get the basic layout in place (so I don't have to deal with calculating rects, etc). Any further customization I prefer to do in code.
You can edit .XIB files by hand if you want to. They're XML, after all. Can't help having at least one of them in the project. Alternatively, you can create all your controls from code. The latter takes less typing, as far as I can tell.
Then, there are some apps where a XIB file would be of no use. I'm talking about games, where artistic/design considerations beat the convenience of having native widgets.
So yes, it's OK on both design level (no native widgets) and implementation level (yes native widgets, but sans IB).
I am considering making use of GWT as the front-end to an existing web application.
I can't justify a complete rewrite to 100% GWT in one go. It is likely that I would migrate parts of the system to GWT gradually. However for consistency I would like to make use of the GWT TabPanel, MenuBar, etc as global interface elements from day one.
As an experiment to see how 'legacy' parts of the system could be incorporated, I have done the following.
The application's main page template now loads a small 'wrapper' GWT module on every page. This GWT module looks for a selection of DIVs in the dynamically generated host page. If the DIV is found, a suitable widget is slotted into place, i.e. menuBar, tabPanel.
A lot of the configuration for the included widgets can also be slotted into the host page as JSON structures. For instance, I have implemented an adapter that dynamically sets up a TabPanel in this way. I've also added some very simple widgets that load remote HTML, etc.
As a prototype, this all appears to work perfectly and loads quickly.
However, it seems that GWT apps are really designed to be run from a single host page, not hundreds of dynamically generated ones.
Can anyone highlight any issues that the above approach may run into, particularly as the GWT module increases in size? I would aim to keep the legacy wrapper module intentionally lean. Other functionality would be implemented in separate modules.
How have other people integrated GWT into their front end in a gradual fashion?
One of the ways GWT was designed to be used is exactly as you've used it. We have done that in many of our apps - where there is one GWT module with multiple 'parts' that are loaded based on whether a given id exists on a page or not. So I don't see that you'll have any issues at all going this way. We often use this approach even for new web applications, where we just want a few 'widgets' on the page, rather than coding the whole application in GWT.
It won't make a huge difference, but one thing I would suggest is not putting the GWT javascript code into your main template, but rather only put it on the pages that need it. It's true that if you're not running HTTPs it is cached basically forever, but it seems wrong to get people to load in the module if it's not actually needed on that page. This of course depends on how people use your site, if they are likely to download it anyway then it won't make any difference.
You're doing it right. Avoid avoid avoid the temptation to try to 'minimize' the GWT footprint by breaking it up into multiple separate apps.
The key to GWT performance is to have as few downloads as possible and to make sure they're cached. Loading a 250k bundle once is much better than two 200k bundles and because compression get's better with larger files you really start to reap benefits as things grow.
y-slow & firebug can be really helpful when it comes to convincing yourself of this.
One performance trick you might check out is available in the sample chapter here: http://www.infoq.com/articles/progwt
It shows a mini-architecture around loading GWT widgets into any number of slots and pre-populating data in JavaScript variables. This allows your GWT widgets to load and not require a second HTTP GET to get the data they use. In practice I found that this was a nice performance boost.