Toolbar style should follow GNOME style

[antistress]

GNOME style can be set to :
text under icons
text beside icons
icons only
text only

phraymd toolbar should follow GNOME style

Note that for "text beside icons" you can choose which which toolbar buttons prioritized
see the the "priority text" setting here http://library.gnome.org/devel/hig-book/stable/toolbars-labels-tooltips.html.en
and here is an exemple http://jeff.ecchi.ca/blog/2009/07/21/toolbar-items-prioritization/

For instance maybe you could decide to display the sidebar label next to its icon if you consider that the corresponding icon doesn't provide a good enough metaphor (see Midori for a sidebar icon exemple) (but it's not the reason why "priority text" setting exist...)
However there could be some i18n problems : for instance "sidebar" would be translated "panneau latéral" in french and that would make a huge button

BTW, note that GNOME 2.28 will switch default style from "text under icons" to "text beside icons" see http://mail.gnome.org/archives/gnomecc-list/2009-July/msg00015.html

[antistress (antistress)]

"For instance maybe you could decide to display the sidebar label next to its icon if you consider that the corresponding icon doesn't provide a good enough metaphor (see Midori for a sidebar icon exemple) (but it's not the reason why "priority text" setting exist...)
However there could be some i18n problems : for instance "sidepane" would be translated "panneau latéral" in french and that would make a huge button"

Totem 2.28 toolbar doesn't follow GNOME Style either, but i've noticed that it has a "sidepane" (or maybe just "pane" - i don't run the english version) button with only the label (without icon) whereas other buttons have only an icon.
Developpers may have good reason to go against HIG sometimes : i guess they didn't find any good metaphor for the sidepane and therefore have renounced to display an icon.

I think you have the choice in "text beside icons" mode for the sidebar : displaying only an icon, or an icon plus a label, or only a label

Note that, in french, the (side)pane button is translated into "panneau" (and not "panneau latéral") which avoids to have huge buttons in the toolbar

[antistress (antistress)]

i've found what is really weird (and looks messy) with current phraymd toolbar : buttons seems to have different heights.
Look at the attach screenshot
Drop-down List is too big and so are Sidebar and Selection buttons. They have the size that they should have with "text under icons" style but without icon in this case (moreover system style is set to "text beside icons" on the screenshot) ! In comparison, icons looks small (Save, Cancel and the broom one)

[antistress (antistress)]

Here is a mockup of current suggestions fo this bug and Bug #380660

[dmoore (damien-moore)]

in rev244, I've refactored the toolbar. this isn't GNOME style, but IMO an
improvement on what it was. We may decide the frames don't work, in which
case I'll switch back to something more like your mockup.

Still to do:
* switch to the fancy entry widget with the embedded "broom" icon.
* more appropriate icon for the sidebar button (I chose leave fullscreen for
now).
* filter entry to expand to use the available space in the window.
* perhaps the sidebar button should appear as the very first item in the
toolbar...

[antistress (antistress)]

Well... sorry in advance for not being positive with latest changes :-/

1°) with rev 246 i understand that the broom icon should be within the search field (Bug #380656) but it's not (whereas i'm running GNOME 2.28 with GTK 2.18)

2°) i've noticed that the "Reverse order" button is still not a toggle button (Bug #380660). I think that this bug is a major one since user don't know what is the current set and therefore is not at ease with the GUI.

Above all :

3°) Sidebar's metaphor is not good to me. The metaphor found in Midori is better - although not perfect. If there is no suitable metaphor, we should not use any icon. Same for the "Reverse order" icon button.

4°) Is it what you meant with "I'm going to replace the toolbar with an HBox" ? i didn't understand. I'm not at ease with the new GUI. It looks very cluttered to me and inconsistent with other GNOME applications. I much prefer the buttons with separators combination !

[antistress (antistress)]

BTW, "filter the view" is basically "search" from a user point of view i think. If so "Search:" would probably be easier to understand

[antistress (antistress)]

BTW the gtk stock undo icon would be better than the one found in phraymd since it's basically an arrow without the sheet a paper (which is not relevant within phraymd)
See Kino or Abiword for instance, and http://library.gnome.org/devel/hig-book/stable/icons-types.html.en#document_icons

[dmoore (damien-moore)]

>Well... sorry in advance for not being positive with latest changes :-/

I have a thick skin. twas just an experiment. check out rev 249

>1°) with rev 246 i understand that the broom icon should be within the search field (Bug #380656) but it's not
>(whereas i'm running GNOME 2.28 with GTK 2.18)

Unless I'm mistaken about how the new gtk entry feature works, I just don't think it has been enabled in pygtk yet. It should work as soon as it gets enabled...

2°) i've noticed that the "Reverse order" button is still not a toggle button (Bug #380660). I think that this bug is a major one since user don't know what is the current set and therefore is not at ease with the GUI.

what do you mean by toggle button? it should show its state the same way as the sidebar button.

>3°) Sidebar's metaphor is not good to me. The metaphor found in Midori is better - although not perfect. If there is no suitable metaphor, we should not use any icon. Same for the "Reverse order" icon button.

I'll draw one if we can't find one (a picture of top left part of a window with sidebar showing, using a bright color to highlight the sidebar in the icon). seems more visually consistent to use an icon for every button.

>4°) Is it what you meant with "I'm going to replace the toolbar with an HBox" ?

sort of. it's actually still a toolbar. If I switch to a generic hbox i'd have better control over spacing, sizing etc

>i didn't understand. I'm not at ease with the new GUI. It looks very cluttered to me and inconsistent with other >GNOME applications.

I don't use that many GNOME apps...

> I much prefer the buttons with separators combination !

which you have now. one issue I had is that i had to manually add labels, because the generic toolitem (used as a container for the sort drop down and filter entry) doesn't support labels.

[dmoore (damien-moore)]

>BTW, "filter the view" is basically "search" from a user point of view i think. If so "Search:" would probably be
>easier to understand

I used "find:" but on second thought "search" might be better if I can't use filter :)

>BTW the gtk stock undo icon would be better than the one found in phraymd since it's basically an arrow without
>the sheet a paper (which is not relevant within phraymd)

personally, the fact that revert to saved metaphor doesn't work is bad design on the part of the gnome icon designers. it's as if the only thing you would ever save is a paper document...

[antistress (antistress)]

1°) good news, can't wait ;-)
2°) sorry, you're right :-)
3°) seems to be a very good idea. Also i've written to <email address hidden> on the off-chance
4°) from my non-developer point of view i don't undersatnd why you can have both label and icon on the same button. I know some python/GTK applications that follow GNOME style (specto for instance http://specto.sourceforge.net/ )

[antistress (antistress)]

sorry my comment was not finished !

Ideally i would like to see :
- both labels and text on buttons (unless you decide to prioritize some buttons in "text beside icon" mode)
- phraymd following GNOME style
- "Changes:" label removed (when 1 and 2 will be fixed, it will look inconsistent. Moreover it seems useless for the user : what could be saved ou canceled aside from changes ?)
- i don't know if it's possible but it would be cool to group the "Find:" label with the search field because at present time if i resize the window width, the search field is hidden whereas the label remains (see screenshot attached)

[dmoore (damien-moore)]

>4°) from my non-developer point of view i don't undersatnd why you can
> have both label and icon on the same button. I know some python/GTK
>applications that follow GNOME style (specto for instance
http://specto.sourceforge.net/ )

Assuming you meant "don't understand why you CAN'T have icon and label on
the button" I'll try this. (You can definitely do this with a normal button,
maybe not a toolbar button --- doesn't matter because it's easy enough to
embed the normal button in a toolitem.)

[antistress (antistress)]

(Note that, after upgrading, i tried to click onto the Sidebar label without success since it's not a button... quite destabilizing !)

[antistress (antistress)]

> Assuming you meant "don't understand why you CAN'T have icon and label on the button"

yes, indeed (sorry again but i've mis-clicked ("post" instead of "add an attachment") and then had no time to correct myself)

> I'll try this.

cool :-)

[antistress (antistress)]

>> 3°) Sidebar's metaphor is not good to me. The metaphor found in Midori is better - although not perfect. If there is no suitable metaphor, we should not use any icon. Same for the "Reverse order" icon button.

> I'll draw one if we can't find one (a picture of top left part of a window with sidebar showing, using a bright color to highlight the sidebar in the icon).

The "new window" icon in Epiphany File menu could be a basis (screenshot taken with Ubuntu Karmic)

[antistress (antistress)]

Sidebar icon : considering my former comment, an arrow would be better than a "+"
an arrow like in GTK_STOCK_FULLSCREEN & GTK_STOCK_LEAVE_ FULLSCREEN would be consistent i think

[dmoore (damien-moore)]

>Sidebar icon : considering my former comment, an arrow would be
>better than a "+" an arrow like in GTK_STOCK_FULLSCREEN &
>GTK_STOCK_LEAVE_ FULLSCREEN would be consistent i think

In rev250 I committed a prototype. It could use some tinkering such as adding arrow(s). The inkscape svg is in phraymd/icons/sidebar.svg (exported as 128x128 png)

>Assuming you meant "don't understand why you CAN'T have
>icon and label on the button" I'll try this.
>(You can definitely do this with a normal button,
>maybe not a toolbar button --- doesn't matter because
>it's easy enough to embed the normal button in a toolitem.)

It turns out that this isn't so easy. default standard Toggle Button wants to show text but no icon. The toolbar ToggleToolButton wants to show icon but no text. grrr...

[antistress (antistress)]

Wow it starts looking good, good work :-)

Looks uncluttered, pleasant and functional : i really like.

With GNOME 2.28 default setting (text beside icon) it now looks integrated
Even if it's not really, since changing to "text under icons" (for instance) has no effect
but this is still a big improvement in the design of the interface if not in real GNOME integration

There is still the need to group the label with the search field (c#13)

Personnaly i think i would prefer having the Search field at the center of the toolbar and sort/order at the right (seems more logical to me) but it may be a matter of taste (see attachments)

Next step : the Configure tab in the sidebar ?

[antistress (antistress)]

i'm not sure that having transparency in the icon is a good idea
see with DarkRoom Ubuntu theme

[antistress (antistress)]

Besides, it would be cool to follow tango color palette (the puple looks unusual to me within GNOME)
http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines

[antistress (antistress)]

Your metaphor is great but why not using rev.249 icon as a basis for window decoration ?
You could use its top horizontal bar (and also its window dimensions) for your icon

[dmoore (damien-moore)]

>i'm not sure that having transparency in the icon is a good idea
>see with DarkRoom Ubuntu theme

that was a mistake... I forgot the background i was drawing against was
contributing to the image :)

>Your metaphor is great but why not using rev.249 icon as a basis for window
decoration ?

That works too, but how are those gnome icons licensed? since you've
basically drawn it now, do you want to supply the icon as svg? To date, I've
been using 128x128 png, but probably should be supplying various sizes.

[antistress (antistress)]

>> Your metaphor is great but why not using rev.249 icon as a basis for window decoration ?

> That works too, but how are those gnome icons licensed?

good question
but i can't find that icon anywhere on the web whereas i can see it on my system running ~$ gtk-demo
GTK+ Reference Manual ( http://library.gnome.org/devel/gtk/ ) has another one ( http://library.gnome.org/devel/gtk/2.18/gtk-Stock-Items.html#GTK-STOCK-LEAVE-FULLSCREEN--CAPS )

On the other hand these icons are under GPL v2 : http://commons.wikimedia.org/wiki/GNOME_Desktop_icons (especially http://commons.wikimedia.org/wiki/File:Application-default-icon.svg )

> since you've basically drawn it now, do you want to supply the icon as svg?
i'd love to but i have no skill for drawing icon, sorry

[dmoore (damien-moore)]

try rev253. not sure about colors. in phraymd/icons you can see alternative
colors for the pane. thoughts?

[antistress (antistress)]

Not bad at all
However i don't think that drawing round corners for the sidepane is a plus. It looks like you're surrounding something, not like a sidepane to me.
As for the color, i'd say that the icon has less affordance in green. Therefore i would pick up the orange or the green one

[antistress (antistress)]

sorry i should have written : "Therefore i would pick up the orange or the red one"

[antistress (antistress)]

To be clear : round corners for gnome default app icon is ok, but i prefer square corners for the sidepane itself

[dmoore (damien-moore)]

I removed the rounded corners and changed pane color to red in rev 256. I
may revisit again in the future but have higher priority stuff to look at
now.

[antistress (antistress)]

Perfect :-)

for later, here are ohter points that have been discussed here :
1°) Toolbar style doesn't follow GNOME style (text under icons, text beside icons, icons only, text only)
2°) it would be cool to group the "Search:" label with the search field because at present time if i resize the window width, the search field is hidden whereas the label remains. Same for the "Sort:" label and the corresponding drop-down list button
3°) Next step : the Configure tab in the sidebar ?

[antistress (antistress)]

Maybe the sidepane icon should be prioritized (=display the label beside the icon) :
the sidepane includes the tag tree which is a very important function in phraymd to me

And maybe that the Tag tab should be the default one when 1st opening the sidepane (to help new users. Other tabs seem to be for more advanced users)

[dmoore (damien-moore)]

>And maybe that the Tag tab should be the default one when 1st opening
>the sidepane (to help new users. Other tabs seem to be for more advanced
>users)

yes, currently the order that tabs appear in is determined by the order that
plugins happen to load in... i.e. randomly. The tag pane is a reasonable
default for first time startup although lovers of folder view may complain
when the folder view plugin is introduced :)

I just implemented the concept of "priority" for the mouseover toolbuttons,
which allows buttons to be ordered more sensibly. I'll do the same for the
tabs in the sidebar. I think we discussed elsewhere that the user should
also be able to reorder the tabs.

[antistress (antistress)]

i don't like the idea of a folder view plugin
it's so 90ies to browse folders
That's the reason why i don't use gThumb
Since then tags have been introduced and to me they are a perfect replacement, not an addition to the old system.
Firefox made the mistake to keep the old hierarchical system when they've introduced tags for bookmarks : they now have both at the same time and i don't like that either.
Rhythmbox and Epiphany for instance don't use the old hierarchical system at all

[dmoore (damien-moore)]

>
> i don't like the idea of a folder view plugin
> it's so 90ies to browse folders
>
That's the reason why i don't use gThumb
> Since then tags have been introduced and to me they are a perfect
> replacement, not an addition to the old system.
> Firefox made the mistake to keep the old hierarchical system when they've
> introduced tags for bookmarks : they now have both at the same time and i
> don't like that either.
> Rhythmbox and Epiphany for instance don't use the old hierarchical system
> at all
>
>
Good arguments against folder view. I promise you that when if and when I do
develop such a plugin it will be disabled by default. The only reason we
care is because about the structure that's how the underlying images are
stored. Now if we could all move to a metadata based filesystem......

[antistress (antistress)]

fair enough :-)