I'm just starting to play around with GTK+ and I wanted to stop bad habits before they happen. I see that GTK+ seems to be a little based in HTML/CSS and I was wondering if there are any reasons to avoid using tables for layout.
The widget structure should reflect the logical structure to help screen readers correctly present the window (sorry - I don't remember the name but it is standard GNOME tool).
If the logical structure is of table form then sure - use it. However if other would reflect them better - use them.
PS. Similarly to HTML where <table> should reflect the tabular data (not necessary so much in GTK+ but still) and should not be used only for layout.
GTK+ is not based on HTML nor CSS, but (lib)Glade and gtkbuilder does use an XML based file format for storing user interfaces. GTK+ is a software library and application programming interface -- it is not a scripting nor layout language.
If you want to avoid bad habits, read the GNOME Human Interface Guidelines, the Windows Human Interface Guidelines or the equivalent for the user interface you are targeting.
Related
I am using wagtail and my user wishes to be able to change font sizes in the Rich text editor. I have attempted to use TinyMCE but the install is problematic (see this question and non-answer)
Is there an alternative that would provide the functionality that I am looking for?
You'd probably consider this a non-answer too, but if a rich text editor with that feature did exist, it would be breaking the design principles of Wagtail. Wagtail is a system for capturing and presenting information, not a web design package, and mixing the two is liable to lead to all kinds of problems down the line (inconsistent styling between pages, difficulty redesigning or migrating the site in future, accessibility for screen-reader users).
The correct alternative is to find out what information your client wishes to communicate with different font sizes, and then make sure you're modelling that information in your page models. For example, if they want to include pull-quotes in their text, you can model the page content as a StreamField with a pull-quote block type (with its own text style defined by you in HTML/CSS). If they don't have any specific informational purpose in mind, and just want to play around with fonts, then gently advise them that that's your job, not theirs...
I've been studying sapui5 framework for some time now and I always used javascript views in my applications.
The question is - are there reasons why should I prefer xml views over javascript, if I should do it at all? If there are some, what are they?
If I want to start trying to write xml views, what is the best place to learn the basic syntax and where can I find API reference for controls created using xml? The SAPUI5 API is written for use with javascript.
Thanks.
Major reason, in my view, is strict separation of concerns. XML views, by their nature, preclude code. Your XML view is therefore strictly presentation logic - a great outcome for professional enterprise development. It also reduces the significant lines of code to code out the ui and thus improves readability and maintenance of code.
the reason I use XML views is because this is the standard approach of the Fiori apps by SAP. It creates a situation where developers only have 1 approach. Also to me they are easier readable.
Generally speaking I see that in the mobile library the xml views are used while in desktop usage js is still leading. On SCN you can find many similar questions.
The library of examples can be found in the same API page under tab EXPLORED.
Perhaps using the webIDE (which offers a local) install can provide a really good base for you to start development using xml based views.
Where you say the API is written for js views, this is true because the controls are written in JavaScript. Look at it this way if you have a namespace in your xml like xmlns:l="sap.ui.layout" any xml element prepended with l like <l:GridData ...
becomes a call to sap.ui.layout.GridData and if you look at the api for this control you can see what attributes you can add to this control / element.
Also if you have xmlns="sap.m" in your namespace block then anything like <Page /> <Table /> become sap.m.Page or sap.m.Table so the api is still a valuable resource and the explored section is great to see controls in action.
I want to represent a Tree in my GWt Project in a another way as the standard graphical
representation.
Drag & Drop should be able.
Like this one:
http://s1.directupload.net/file/d/2603/yzo588bb_jpg.htm
Do you know a good GWT Extension to realize this?
I have already looked at the Google Web Toolkit Gallery.
Do you think something like this would solve the problem?
http://gwtgallery.appspot.com/about_app?app_id=86
I'm using Raphaël Gwt for such graphic stuff.
I've tried Vectomatic once, but it is no fun to write, because it seems like the author had no Idea what a namespace is (Several classes starting with OMSVG) and it doesn't "feel" like writing a java programm.
On the other side, with Raphël-GWT is a binding to a javascript-library, thus you have (llittle) Preformance tradeoff for loading an external Cross-browser javascript library.
There's a question about using layout managers in GWT, which was however answered in the sense that no direct porting of Swing apps is possible. But I don't need this, I only want to use a sane way of positioning.
Is there a a port of MigLayout (or alike) to GWT?
Since a LayoutManager is mostly a way to set the component sizes and positions using some user preferences, it should be possible. Doing this for a HTML component is possible (and AFAIK some frameworks compute all sizes and positions on the server and avoid all associated HTML/CSS problems).
Depending on your definition of crazy, the LayoutPanels built in to GWT are quite sane. There's a DockLayoutPanel with familiar north/south/east/west behavior, and also panels that allow more arbitrary percentages and positions. Combining them with CSS is very powerful and flexible.
http://code.google.com/webtoolkit/doc/latest/DevGuideUiPanels.html
Although requested years ago, it looks like it hasn't been done yet.
Just one quotation:
I'm just getting started with GWT and I feel like I just stepped back into the dark ages with all the various layout panels and layout managers.
There's gxt-jglayout, which is JGoodies form layout implementation for Ext-GWT (GXT), but Ext-GWT is not free (it's dual licensed).
I am looking for a nice framework for developing a GUI builder Application. We have an application where 100Os of custom data entry forms and their print formats are required and each client will need some modifications on these. We have a developed a product using java based open source templatnig frameworks so that the layout and field definition are stored in database and rendered dynamically to the user. We also have an appication to design these forms but cannot do visual design.
Now I am trying to make a Visual Form Designer application for generating these forms. Can any one suggest some open source frameworks than can be used? Can I use Eclipse Visual Editor? Or is it better to develop some kind of parser for HTML using AntLR and then parse the HTML output from already existing GUI builders like Dreamweaver to get the desired output?
Thanks and Regards,
-- Kannan
Oooh, great question!
I wouldn't know any readily availble framework that you can use. Depending on your needs however, I think rolling your own shouldn't be too hard.
First of all, you probably wouldn't want to give the users too much freedom. Freedom only gives them the opportunity to mess things up and make the resultant forms hard to use. I think from your description that the fields are pre-defined, so that the user only needs to customize which fields appear on a given form, and in what order. Order can be a simple thing like top-to-bottom. Some semi-intelligent automatic layouting could be used to conserve screen space. Adding a feature to group fields together would probably also be useful, and grouping would lead to some kind of standard "group" widget.
Accepting simplified functionality like this, you don't really need the flexibility of a full gui editor. A couple of listviews, maybe a property sheet and a preview window will be enough to give your users the functionality they need.
Of course, this only holds for screen forms. Print forms may be trickier to layout, as people may want to cram as many fields as possible into very little space so the entire form can fit on a single page or something. I really don't have any suggestions for you there, but maybe a similar "simplified" approach with some intelligent auto-layouting could work.
Overall, my advice would be: Keep It Simple! (S... ;)