Hi, Am Montag, den 22.08.2005, 19:35 +0200 schrieb A.J. Venter: > > > Oh I've heard their arguments, I even agree with them. It's their METHODS > > > I don't approve off. > > > > Works pretty well... all gnome apps more or less feel the same. I can > > use all of them with minimal learning. Which should be the point, cause > > I dont use the comp to play around with fonts but to get some actual > > work done. > > > > Note that your actual problem comes from the fact that you use a > > pixel-based widget placement scheme. Your app translated into chinese > > will not look good with a pixel-based widget placement scheme either. Or > > hebrew, or any of the "double-width" languages. Or a top-down language. > > Or on a 10000x10000 pixel monitor. Or on a 320x240 pixel monitor. It > > will look crap on anything _but_ exactly the system you developed it on. > > This is bad. > > Right I'm gonna quit the flamewar (which is OT) and talk about this (which > isn't). Actually I've done quite a bit to reduce the problem this is.
if you want a per-application theme, call gtk_rc_parse('filenamerc'); at
the beginning.
I see from the screenshots that with your design, keeping the font size
down a bit is actually required (well, not really totally _required_,
but nicer) for the somewhat-toolbuttons at the top.
> For starters I created in
> olpack(http://silentcoder.co.za/viewsvn/viewsvn.php?project=lazarus&path=%2Folpack%2F)
>
> the screensize component, these particular apps, by their very nature are
> used alone, so they run maximized. Since lazarus doesn't (yet?) obey
> ws_maximized, I use the screensize to get the
Tell me how the code to set ws_maximized looks, and I can check if the
gtk backend of lazarus handles it, and fix it. Is it just via
"windowstate" ?
> current X geometry, and tell auto-resize my main-window to follow it, relying
> on the window manager to limit me to the REAL usable space (e.g. not over a
> protected taskbar) (btw. screensize uses xlib directly so it has no new
> dependancies and is incredibly low on overhead).
I see
>
> Next, I only have one window. My "dialogs" are in fact groupboxes which I use
> to create a very good fake of an encapsulated dialog - the whole thing looks
> very nice. Using anchors, they scale with the window.
>
> So I am pretty much scaling everything natively anyway. The trouble comes
> with
> the icon-buttons on top (TBitButtons) which actually open the different
> dialogs. These babies cannnot just scale freely, they must be constant in
> vertical size (so I can at least have a constant .top value for dialogs) and
"Constant" .top value ? well, after the dialog has been rendered on
screen, you can read the "constant" top value, which doesnt change until
the theme changes and the buttons change to triangles or something :)
It has been years since I did anything with pixel addressing, so please
bear with me...
> the must at their smallest size fit into the window all next to each other
> WITHOUT scrolling even at 640x480 - which is the lowest resolution I really
> DO need to support (there is something to be said for not wasting time on
> what really isn't ever going to affect YOUR users).
(OT) btw java has a "flowlayout" that will just put the buttons that
dont fit into the next "row", without putting a horizontal scrollbar.
Wonder why nobody else has it... or does lazarus ? I'm always happy to
be proven wrong :)
>
> Perhaps some screenshots will clarify what I mean better:
> http://www.silentcoder.co.za/tiki/tiki-browse_gallery.php?galleryId=15
>
> Notice the buttons on the user page - at 640x480 they just about fill up all
> available space horizontally. So there is nothing for it, the font on them
> has to fit to THEM not the other way around.
well, that's going to be though. I know of no system that calculates
"the other" way around, which seems to be what you want here. Like this:
(pseudo-code that just happens to resemble pascal a bit)
const MinFontSize = 10;
for each fontsize := 1000 downto MinFontSize do begin
allwidth := 0;
for each button in window.Children do begin
r := button.Canvas.TextRect(fontsize, button.Caption);
r.Width := r.Width + button.border * 2 + 2; (* this, too is an
implementation detail *)
r.Height := r.Height + button.border * 2 + 2; (* this, too is an
implementation detail *)
allwidth := allwidth + r.Width;
end;
if allwidth <= window.clientwidth then begin
for each button in window do begin
button.fontsize := fontsize;
end;
Break;
end;
end;
Which would be nice in your case, but not sure if it is possible to do
easily (especially getting rid of the implementation detail and instead
have something like Calc_Button_With_Caption_Width_At_Font_Size by the
widget system, since nobody guarantees that the buttons are even square
shaped)
> I don't know how any OTHER type of placement policy could possibly address
> this (though I'm happy to learn).
any other placement policy than fulfils which criterias ?
Scaling down widget fonts dependent on the window size ?
Cant think of any that does that yet.
> One thing I am adamant on is that any app
> which scrolls horizontally is badly designed. Even vertical scroll should be
> avoided if at all possible. If it HAS to be there, it must be limited to data
> presentation. A user should NEVER need to scroll to find an application
> control, controls that are not clearly visible are by default not user
> friendly.
agreed.
>
> Ciao
> A.J.
cheers,
Danny
--
www.keyserver.net key id A334AEA6
signature.asc
Description: This is a digitally signed message part
