[maemo-developers] [maemo-developers] RFC: Redesigning the HildonApp+Views

From: Simon Budig simon at budig.de
Date: Tue Dec 20 16:34:37 EET 2005
Komulainen Tommi (Nokia-M/Helsinki) (tommi.komulainen at nokia.com) wrote:
> On Sat, 2005-12-17 at 01:27 +0100, ext Simon Budig wrote:
> > 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.

True. However, it is a noble goal to try to keep the differences to a
minimum  :)

> > 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.

Yeah, that would be solved automatically if each Appview has its own
GtkWindow (or whatever the new approach is). Some Windowmanagers (or
panel applets) implement a grouping-by-application mechanism, so that
the number of buttons in the panel is kept to a minimum. Something like
this would help the TN as well, especially since there is only room for
four or five icons.
 
> > 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? :)

Heh  :)

Actually I am just reading the Gnome coding styleguide and I am
surprised that they suggest 8-space tabs. That is IMHO too much, but I
don't really want to discuss this...  :)
The gimp coding style is basically GNU coding style with a few
extensions, see the "Hackordnung" at http://developer.gimp.org/HACKING .
Without really looking into it I'd guess that GTK+ is very similiar.

When reading the hildon header files there are two things that bug me
most: The lack of a space before an opening parenthesis (which makes it
harder to separate the function name from the first arguments type) and
the lack of vertical alignment.

For an experiment try to quickly spot all the function names declared in
   http://www.home.unix-ag.org/simon/files/n770/hildon-app.orig.h
(which is an unmodified copy of the original file)

and then try the same with
   http://www.home.unix-ag.org/simon/files/n770/hildon-app.indent.h
where I have applied some GIMP coding style  :)  (most notably the
vertical alignment, which is - as I realize now - not explicitely
mentioned in the Hackordnung).

Anyway - as you say, this is a can of worms and it is sometimes fun to
open one, but don't let that distract us from the bigger issues  :)

Bye,
       Simon

-- 
              simon at budig.de              http://simon.budig.de/


More information about the maemo-developers mailing list