On Sat, 2005-12-17 at 01:27 +0100, ext Simon Budig wrote: > Hi. > > Tommi Komulainen ([EMAIL PROTECTED]) wrote: > > Essentially the change would be to introduce a new widget (maybe > > HildonWindow or something) that would replace current HildonAppView. The > > new widget would be a real GtkWindow / toplevel X window which will > > require code changes when migrating the the new API, but in the longer > > term, once we drop the old views, reduce overall complexity. > > Yeah, the concept of multiple views in an app struck me odd. I can see > reasons for having multiple views, but I don't see what is the benefit > over having multiple "GtkWindows" aka HildonApps.
Hysterical raisins. We needed to have application modal dialogs and at that time introducing the concept of "views" was more simple. These days it's more simple to make the window manager do it. > Right now the code has to dive into different codepaths for native GTK > vs. Hildon, so that hildon gets an appview into the window and the rest > of the UI gets packed into the appview, it would be cool to get rid of > that need. Having the new widget derive directly from GtkWindow should help in that. However you will still need to do handle menus and toolbars slightly differently. > > * unmodified gtk+ applications using GtkWindows will be accessible > > through the task switcher > > This cannot be solved by a new widget. This needs to be solved at the > taskswitcher-level, preferrably by implementing the relevant parts of > the freedesktop wm-spec standards. This will give you a list of the top > level windows and you then can retrieve the icons as provided by the > application. You're of course correct. I left that bit out basically because the specs already exist, so there's not much more effort needed there - only to reuse what's already there. > > * the new API should be as similar (toolbars) as possible, or in > > places more sane (key handling, fullscreening) than with > > AppViews > > Just from looking at the hildon header files: deprecate > hildon_appview_set_fullscreen() and use gtk_window_(un)fullscreen() > instead. > > Yeah, I am aware that an appview is not a window, but this is something > that needs to be cleared up. It does not really make sense to have two > appviews that both belong to the same hildonapp (read GtkWindow) and one > is fullscreen and the other is not. You shouldn't think of views as anything fancy, they're just an implementation detail. Logically they're just windows, though you can only ever see one at a time. I think it is better to have that option, then you have more options to do application UI design. Whether that design is a good one is a different question :) > For me the semantics of having multiple appviews is more like a big > GtkNotebook with invisible tabs. If the individual appviews should > appear in the task switcher might depend on the application and might > need to use an additional method to inform the task switcher about the > appviews, the task switcher then probably should display the appviews in > a kind of menu. It confuses the heck out of me to see two globes in the > task switcher, click on the lower one and suddenly the upper one gets > active (yeah, I know it is not like that, but it looks like that). Well, the TN does know the application and how many views it has and shows them in the task switcher without any additional menu. The problem with identical icons is one of the reasons we want the new widget - custom icons come naturally with the windows, but supporting the same thing with appviews would be painful. > Oh yeah - GIMP-like coding style for the headerfiles and the code :-) Ooh, let the coding style wars begin! I'm familiar with GNOME and gtk+ coding style, how does gimp style relate to those? :) -- - Tommi _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
