On Wed, Jun 21, 2017 at 11:26:07AM +0100 I heard the voice of
Aaron Sloman, and lo! it spake thus:
> 
> Yes. If I were younger, fluent in C, and had more time to spare, I
> thought it would require something like the following list of
> additions:

That certainly sounds a lot more involved than I'd imagine.  I'd just
add name_override and icon_name_override fields to override the window
name (what we show on the title bar) and icon name (what we show as
caption on icon / entry in icon manager), respectively.  Functions to
set them.  And just use them if they're set; no reason to add extra
functions to toggle showing them, just don't set 'em if you don't want
to show 'em...


> An extra option could be added to ctwm menu items or function calls
> that are capable of creating a new window

Hard to imagine how you could do that.  How could you possibly know
where a window came from?  You could do horribly invasive hacks with
trying to cross-reference PID's, maybe, but even that will fail as
soon as you run something that does any forking...


But, most obviously:

> then displays a panel with a text field into which text for a label
> can be typed,

Text field?  Type into?  You can't do any of that stuff.  Or rather,
you can't without using some sort of widget library.  Or writing your
own, but...   no.  So that means we get to have the discussion of when
we get to say "ctwm requires the Athena widget libs".  Or Motif?  Or
maybe we should go GTK.  Or...

(I've certainly thought a time or ten of places it would be nice to
have actual UI widgets, like text entry, or scrolled lists, or...
there are lots of possibilities)



-- 
Matthew Fuller     (MF4839)   |  [email protected]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.

Reply via email to