I have created with Glade a fairly complicated UI and often there are unused GtkGrid locations. I was filling them with blank labels but now I'm thinking that's silly and I should just leave them blank. I believe (not 100% sure) that Glade puts <placeholder/> tags in those locations.
If I leave them as placeholders, does that leave the behaviour somewhat undefined or at risk of some weird thing happening depending upon platform or operating system?
Note: It does seem to usually be possible to avoid placeholders with carefully constructed grids in grids.
Related
I don't know if this is the right place to ask this question but I figured I might as well try to get an answer here.
My problem is the following: I'm a huge fan of Bootstrap and all there components so I'm genreally using them in every project im working on. So when I'm using container and container-fluid with different row's in between for sertain content-elements I haven't figured out a way to implement this inside the backend in an user-friendly way.
The way I used to do it was simply use the Grid Elements Extension to simply create containers, row's and col's and implement those within each other in the backend. Works fine, but its a whole lot of work for the user of the site to create content. I don't know if my explenation was clear, english isn't my first language and I don't know how to describe it in another way, but here's a picture of what I'm trying to say:
As you can see there are a lot of elements nested within each other so the user or admin has to actually "know" how bootstrap works to edit content without destroying the layout.
Is there any other way I can achive full flexibility for the content, e.g. a bunch of container's within a container-fluid as a wrapper and another bunch of cols's as children of the container?
I've tried to work with Mask, which seemed to be the solution at the beginning, but in the end I had to create one mask object for every possible way an element could be loaded, so there goes this option..
Does anyone else have this kind of "problem" or is there a simple (or hard, idc) solution I can use?
Thank you guys :)
I understand your "problem". My opinion: As soon as you have a page layout with multiple containers (container / container-fluid) and a flexible grid layout, I guess there is no better way without restricting flexibility or have some dirty logic / code. In some (minor) cases, you can help yourself with layout classes (DB field "layout") and some logic in fluid + a viewhelper to calculate the grid columns (e.g. imagegallery, where you can set the columns in backend and calculate the columns in frontend). But in my opinion, this is the most flexible way.
There are some people who solve this with new content elements and inline relation to its content elements. But IMHO this is more confusing for editors to see a grid layout in the backend and the possibility to flexible add content elements via content element to the container / column of choice.
A small, but effective useful helper for editors is to colorize your grid elements in the backend to help the editor to recognize different grids.
In my experience, editors can handle nested grids better than searching for multiple dropdowns in elements to understand grids.
Offtopic: editors survived templavoila, they will understand grids :-)
What is the difference between Stackpanel and Stacklayoutpanel?
According to the Dev Guide, StackPanel is deprecated and you should use StackLayoutPanel. Basically StackPanel works only in quirks mode, while StackLayoutPanel works only in standards mode, as well as being rooted on the RootLayoutPanel, not the RootPanel.
The LayoutPanels are a newer collection of panels that have much more predictable behavior across browsers. When given a choice, prefer anything based on the Layout system.
This is waaaaay oversimplified, but on a general level, all of the layout panels are more "div" like, vs. the original panels being organized in tables.
So, when you want to do predictable stuff across disparate screen sizes, etc., the layout stuff does what you've come to expect. So definitely use them over all else. In fact, if you're trying to use GWT for the ease of writing in Java and ignoring web design, use as many FlowPanels with css as possible.
I'm fighting to understand the weird behavior of GWT Layout Panels. I'm wondering how GWT translate Layout logic into javascript and html. sometimes we don't get the expected Layout . something under the cover is done by GWT compiler.
the GWT documentation is not clear enough on how Layout is performed under the cover.
is there some good books or tutorials that explains well the GWT Layout issues?
thanks.
I don't know about good books or tutorials but here's a little information that may be helpful.
First, as you may know there's a big difference between the FooPanels and the FooLayoutPanels. These are two different sets of panels that are based on different layout mechanisms. The Layout Panels are the new stuff that seems to be suited better for layouts that have hard-coded sizes, Google Wave style. The older FooPanels (VerticalPanel, etc.) are based on HTML tables mostly.
FlowPanel - this is simply something that outputs your widgets as successive HTML elements in a single DIV. As documented: "A panel that formats its child widgets using the default HTML layout behavior".
DockLayoutPanel - Looking at the code shows that it hard-codes the sizes of the different regions according to what you specify in the children (north, east, etc.)
Finally - my experience has led me to abandon all usage of the Layout Panel system and rely only on HTML and CSS wherever I can. This means using HTMLPanel + UiBinder mostly and sometimes FlowPanel, rarely also some of the other panels.
Trying to understand and battle the Layout Panel system to do things that are not the "default case" was a waste of time. I'm not saying it's the best thing to do, but I just couldn't get the kind of control I wanted without this - especially with regard to elements that should automatically expand vertically. If you haven't already, take note of this from the GWT documentation about Layout Panels:
The panels described above are best used for defining your application's outer structure — that is, the parts that are the least "document-like". You should continue to use basic widgets and HTML structure for those parts for which the HTML/CSS layout algorithm works well. In particular, consider using UiBinder templates to directly use HTML wherever that makes sense.
I've yet another question. I'm working with GWT 2.0.4 and IE8 as well as FireFox (the latter only for comparison purpose). My application needs to load data and show it inside a table. There are about 60 columns and 150 rows to show.
Since the loading is dynamic - as soon as a dataset has been fetched, it's added to the table - I'm fine with slowdowns during loading process. However: when the table is completely loaded, I'd expect it to be pretty snappy and let me scroll it without much lag.
While the loaded table reacts in FireFox pretty good - it stays very responsive - Internet Explorer 8 is causing me a lot of headaches. In particular: as soon as the table finished loading and I try to scroll around or highlight a row, IE8 becomes VERY laggy and highlighting a row makes IE8 consume 50+% of CPU power.
I am not using any 3rd-party libraries and even displaying empty cells in a FlexTable still gives me the same issue.
I found some probably related issue here: SmartGWT ListGrid is slow, but only in Internet Explorer . Unfortunately neither the issue there, nor the supplied links for SmartGWT solved my problem as I am not using SmartGWT. I do believe though that the problem is related.
I'd be happy to try any suggestions.
If it's possible (and your description of the problem suggests so), use Grid instead:
A rectangular grid that can contain
text, html, or a child Widget within
its cells. It must be resized
explicitly to the desired number of
rows and columns.
Have a look at bulk table renderers # GWT Incubator for a comparison of these approaches (it's a little dated, but the point that FlexTable is slower than Grid still holds ;)). The "bulk rendered" tables from the incubator are also an option, however keep in mind that those widgets might not be maintained any more (and for example, contain bugs) - or are rapidly maintained :D But looking at the source might at least point you in the right direction, if you wanted to roll out your own solution to this problem.
highlighting a row makes IE8 consume 50+% of CPU power.
Maybe it's because you added mouse listeners to every row in your table. If so you could use :hover-pseudo-class in your css-files.
This article maybe helpful if you need to handle Events from a bunch of widgets in your table: http://code.google.com/intl/en/webtoolkit/doc/latest/FAQ_UI.html#As_the_application_grows,_event_handlers_seem_to_fire_more_slowl
I'm implementing a document viewer with highlighting/annotation capabilities for a custom document format on iPad. The documents are kind of long (100 to 200 pages, if printed on paper) and I've had a hard time finding the right approach. Here are the requirments:
1) Basic rich-text styling: control of left/right margins. Control of font name, size, foreground/background color, and line spacing. Bold, italics, underline, etc.
2) Selection and highlighting of arbitrary text regions (not limited to paragraph boundaries, like in Safari/UIWebView).
3) Customization of the Cut/Copy/Paste popup (UIMenuController) This is one of the essential requirements of the app.
My first implementation was based on UIWebView. I just rendered the document as HTML with CSS for text styling. But I couldn't get the kind of text selection behavior I wanted (across paragraph boundaries) and the UIMenuController can't be customized from within UIWebView.
So I started working on a javascript approach, faking the device text-selection behavior using JQuery to trap touch events and dynamically modifying the DOM to change the background color of selected regions of text. I built a fake UIMenuController control as a hidden DIV, positioning it and unhiding it whenever there was an active selection region.
Not too shabby.
The main problem is that it's SLOOOOOOOW. Scrolling through the document is nice and quick, but dynamically changing the DOM is not very snappy. Plus, I couldn't figure out how to recreate the magnifier loupe, so my fake text-selection GUI doesn't look quite the same as the native implementation. Also, I haven't yet implemented the communication bridge between the javascript layer and the objective-c layer (where the rest of the app lives), but it was shaping up to be a huge hassle.
So I've been looking at CoreText, but there are precious few examples on the web. I spent a little time with this simple little demo:
http://github.com/jonasschnelli/I7CoreTextExample/
It shows how to use CoreText to draw an NSAttributedText string into a UIView. But it has its own problems: It doesn't implement text-selection behavior, and it doesn't present a UIMenuController, so I don't have any idea how to make that happen. And, more importantly, it tries to draw the entire document all at once, with significant performance degradations for long documents. My documents can have thousands of paragraphs, and less than 1% of the document is ever on screen at a time.
On the plus side, these documents already contain precise formatting information. I know the exact page-position of every line of text, so I don't need a layout engine.
Does anyone know how to implement this sort of view using CoreText? I understand that a full-fledged implementation is overkill for a question like this, but I'm looking for a good CoreText example with a few basic requirements:
1) Precise layout & formatting control (using the formatting metrics and text styles I've already calculated).
2) Arbitrary selection of text.
3) Customization of the UIMenuController.
4) Efficient recycling of resources for off-screen objects.
I'd be happy to implement my own recycling when text elements scroll off-screen, but wouldn't that require re-implementing UIScrollView?
I'm brand-new to iPhone development, and still getting used to Objective-C, but I've been working in other languages (Java, C#, flex/actionscript, etc) for more than ten years, so I feel confident in my ability to get the work done, if only I had a better feel for the iPhone SDK and the common coding patterns for stuff like this. Is it just me, or does the SDK documentation really suck?
Anyhow, thanks for your help!
Does your document have any semantic components other than each paragraph? If you already have some concept of sections or pages, I would recommend you render each one of those as an independent tablecell. It's pretty simple to create a tablecell that makes you forget you're actually looking at a UITableView. All you would need to do is override drawRect: and setSelected: and setHighlighted: and tah dah! No More cell dividers unless you want them. Furthermore you could do some nifty things by using a tableview as your base. If you defined sections in the UITableView then you could have a nifty header that scrolls along as you're paging through your document. Another thing you could do is add a "jump to section" bar / a bookmarks menu, and that way you don't have to provide selection across the boundaries of sections.
Massive copy paste blocks would be pretty painful on the system as well. Further, if you went through the trouble to provide this content you might not want to make it too easy for someone to copy it all at once... (Can't follow this line of thought more without more specifics on your project).
If you really do want to provide the copy paste options you could add buttons to each logical page or section that immediately selects and copies the whole section for the user's convenience. (Maybe with citation associated?)
I recommend you lookup the UITableViewCell UITableViewDelegate and UITableViewDataSource in the SDK docs as those pages will significantly help if you choose to use this suggestion.
Just two random observations:
Can you afford to create a paging interface? (As opposed to “endless scrolling”.) It looks like a paging interface would be a lot easier on system resources.
The UIActionBar is actually the UIMenuController class. The interface is a bit weird, as the menu is a singleton (wtf?), but I’m sure you’ll have no trouble figuring it out.
Hope that helps.
Here's a potential solution, but I don't know if it's crazy. Since I'm still so new to iPhone development, this might be a big no-no.
Anyhow, I had the idea to render each paragraph of the document (whose dimensions I've already precisely calculated) as a cell in a UITableView. Since UITableView already has mechanisms for cell recycling, I wouldn't have to implement that from scratch, and the document could be arbitrarily long without causing resource consumption problems.
Of course, I'd want to get rid of the line separators between cells, since I want the UI to look like a document instead of a table.
Or maybe I could render each page of the document (like a typical PDF, this is a paged-document format) as a table cell, and override the cell-separator graphic to look like a page boundary...
But would it be possible to get rid of the default touch behavior within the table, and instead implement text-selection on the table cell contents? Would it be completely impossible to implement text selection that crosses paragraph boundaries (between multiple table cells)?
The UIWebView is a good choise, but we need another application to pre render the pages percisely using each font and each style sheet and store the rendring information into a database table:
chapter_id int primary key,
startlocation int,
end location int,
fontsize int (or stylesheetname string)
Using JavaScript we can calculate how many words fit in a div with out scrolling.
UIWebView is good as it provide rich content and it has selection and highlighting behavior.
Hope this helps.