|
|
 Up |
|
|
  |
Author: Jon HarropJon Harrop Date: Oct 13, 2007 22:50
Joachim Durchholz wrote:
> dkf schrieb:
>> Out of curiosity, what are those "broken, hard wired assumptions"?
>
> Stuff like:
> * Grid cells, treeview labels, and menu entries can have only text.
> Oh, wait, you can have an icon, too. (That's what you have to deal
> with on Windows. There are workarounds, but they are... ewwww.)
Is that true of Windows Presentation Foundation?
> * You don't get back all the parameters of a control.
> * You don't get all the relevant dimensions of a control.
> (E.g. for a text input control, you need outer borders, inner borders,
> the position of the actual text area, and the text baseline.)
And that's just for Latin derivatives....
> (The "broken assumption" in the "you don't get" items is that the
> programmer will never need these values. Try to line up a label's
> base line with the base line of a text input field and you know what
> I mean.)
That problem plagues HTML even more, IMHO.
|
| Show full article (2.52Kb) |
|
| | 22 Comments |
|
|
Author: Joachim DurchholzJoachim Durchholz Date: Oct 14, 2007 06:51
Jon Harrop schrieb:
> Joachim Durchholz wrote:
>> dkf schrieb:
>>> Out of curiosity, what are those "broken, hard wired assumptions"?
>> Stuff like:
>> * Grid cells, treeview labels, and menu entries can have only text.
>> Oh, wait, you can have an icon, too. (That's what you have to deal
>> with on Windows. There are workarounds, but they are... ewwww.)
>
> Is that true of Windows Presentation Foundation?
Dunno.
My practical experience is limited to the classic GDI functions.
As far as I can tell from a few cursory looks through the docs, GDI+
(the .net equivalent of GDI) is a lot better but is still limited.
I know even less about WPF, so I'll leave that to others to comment upon.
|
| Show full article (3.62Kb) |
|
| | no comments |
|
|
Author: Ken TiltonKen Tilton Date: Oct 14, 2007 09:41
Jon Harrop wrote:
> Joachim Durchholz wrote:
>
>>dkf schrieb:
>>
>>>Out of curiosity, what are those "broken, hard wired assumptions"?
>>
>>Stuff like:
>>* Grid cells, treeview labels, and menu entries can have only text.
>> Oh, wait, you can have an icon, too. (That's what you have to deal
>> with on Windows. There are workarounds, but they are... ewwww.)
>
>
> Is that true of Windows Presentation Foundation?
>
>
>>* You don't get back all the parameters of a control.
>>* You don't get all the relevant dimensions of a control.
>> (E.g. for a text input control, you need outer borders, inner borders,
>> the position of the actual text area, and the text baseline.) ...
|
| Show full article (2.93Kb) |
| no comments |
|
|
Author: Mark TarverMark Tarver Date: Oct 14, 2007 18:40
On 14 Oct, 17:41, Ken Tilton optonline.net> wrote:> Jon Harrop wrote:
>> Joachim Durchholz wrote:
>
>>>dkf schrieb:
>
>>>>Out of curiosity, what are those "broken, hard wired assumptions"?
>
>>>Stuff like:
>>>* Grid cells, treeview labels, and menu entries can have only text.
>>> Oh, wait, you can have an icon, too. (That's what you have to deal
>>> with on Windows. There are workarounds, but they are... ewwww.)
>
>> Is that true of Windows Presentation Foundation?
>
>>>* You don't get back all the parameters of a control.
>>>* You don't get all the relevant dimensions of a control.
>>> (E.g. for a text input control, you need outer borders, inner borders,
>>> the position of the actual text area, and the text baseline.)
> ...
|
| Show full article (4.68Kb) |
| no comments |
|
|
Author: Ken TiltonKen Tilton Date: Oct 14, 2007 19:09
Mark Tarver wrote:
> On 14 Oct, 17:41, Ken Tilton optonline.net> wrote:
> >>Jon Harrop wrote:
>>
>>>Joachim Durchholz wrote:
>>
>>>>dkf schrieb:
>>
>>>>>Out of curiosity, what are those "broken, hard wired assumptions"?
>>
>>>>Stuff like:
>>>>* Grid cells, treeview labels, and menu entries can have only text.
>>>> Oh, wait, you can have an icon, too. (That's what you have to deal
>>>> with on Windows. There are workarounds, but they are... ewwww.)
>>
>>>Is that true of Windows Presentation Foundation?
>>
>>>>* You don't get back all the parameters of a control.
>>>>* You don't get all the relevant dimensions of a control. ...
|
| Show full article (5.05Kb) |
| no comments |
|
|
Author: Ulf WigerUlf Wiger Date: Oct 15, 2007 04:47
Ken Tilton wrote:
>
> Not to worry, I abuse these yobbos for fun, not out of anger.
Well, nice to hear that you're enjoying yourself.
Personally, I'm thoroughly unimpressed by the act of
abusing others for one's own entertainment.
(Perhaps I'm overly sensitive because I don't frequent
comp.lang.lisp, but only get a whiff of this kind of
attitude when it crosses over to comp.lang.functional.)
I contributed one post to this thread, referring to
Joe Armstrong's GUI toolkit in Erlang. I mentioned that
it has failed to gain support. It was not because the
programming model wasn't excellent - it was. It was because
most prospective users would not be interested until it
could compete aesthetically with mainstream GUIs. No-one
doubted that it could be done elegantly, but no-one
volunteered to put in the enormous amount of work required.
Amazingly, the whole discussion played out without insults.
|
| Show full article (0.92Kb) |
| no comments |
|
|
Author: Ken TiltonKen Tilton Date: Oct 15, 2007 08:05
Ulf Wiger wrote:
> Ken Tilton wrote:
>
>>
>> Not to worry, I abuse these yobbos for fun, not out of anger.
>
>
> Well, nice to hear that you're enjoying yourself.
> Personally, I'm thoroughly unimpressed by the act of
> abusing others for one's own entertainment.
Well the yobbos like it. It's a kinky little S&M/bondage/domination
thing they're into.
|
| Show full article (1.91Kb) |
| no comments |
|
|
Author: Joe EnglishJoe English Date: Oct 15, 2007 09:15
Joachim Durchholz wrote:
>
> The GUI framework I have worked on had some size adaptation techniques,
> and it turned out that the thing became immensely complicated after
> acquiring too many ways to let the constraint information flow. We had
> all kinds of problems propagating the constraints across the container
> hierarchy: endless cycles, surprising effects, overcomplicated and
> moderately difficult-to-maintain code that worsened little by little,
> and the rare case where a desired behaviour couldn't be easily
> expressed. A constraint solver would have been just as complicated as
> what we had, but it wouldn't have had that complication creep.
Motif, Xaw, and most other toolkits I've used have had
similar problems, with the notable exception of Tk.
In Tk, geometry propagation is strictly a two-pass process: an upward
pass to compute the required size of all windows, and a downward
pass to do the placement. Nodes in the layout tree only need to
know about their immediate children, and complicated constraint
propagation is unnecessary.
|
| Show full article (1.23Kb) |
| no comments |
|
|
Author: Jon HarropJon Harrop Date: Oct 15, 2007 10:41
Ulf Wiger wrote:
> I contributed one post to this thread, referring to
> Joe Armstrong's GUI toolkit in Erlang. I mentioned that
> it has failed to gain support. It was not because the
> programming model wasn't excellent - it was. It was because
> most prospective users would not be interested until it
> could compete aesthetically with mainstream GUIs. No-one
> doubted that it could be done elegantly, but no-one
> volunteered to put in the enormous amount of work required.
That's very interesting. Could you explain exactly what it is about Joe's
toolkit that makes it attractive from a programmer's point of view? Does it
separate design from logic so that non-coders can work on the GUI alongside
coders?
Also, would it take much work to write a back end in OCaml that targets
something like Smoke's declarative vector graphics:
http://www.ffconsultancy.com/products/smoke_vector_graphics/
I think it would be great to bridge the current gap between GUI libraries
for Linux and freeform rendering using OpenGL etc...
|
| Show full article (1.12Kb) |
| no comments |
|
|
|
|
|
Author: Joachim DurchholzJoachim Durchholz Date: Oct 15, 2007 13:31
Joe English schrieb:
> This is one of the things that Tk gets right. Tk's layout
> mechanisms have a flexibility-to-ease-of-use ratio that's
> unmatched by any GUI toolkit I've seen.
I once dabbled with Tk, and I agree.
However, I dimly remember that its layout model covers roughly 90%% of
cases, and that there was no good way to cover the remaining 10%%. (IIRC
the issue was that it cannot divide up a size increase over several
controls.)
So while Tk is a good application of the KISS principle, it's not a
complete solution.
Regards,
Jo
|
| |
| no comments |
|
|
|
|
