Re: [dev] SWK: The simple widget kit

Hi

----- Original message -----
> On Sun, 09 May 2010 04:58:46 +0200
> pancake <pancake_AT_youterm.com> wrote:
>
> > Applied.
> >
> > I was expecting a diff, but bundle is ok too :)
> >
> > The debug printfs you removed are ok..i mean.. I was using them for debugging
> > purposes, and its not something to be in mainstream.
>
> I only moved one fprintf to a different line in the same block, so that
> it would provide accurate debugging information.  (When I saw the test
> program printing out a keycode from the previously received event, I
> was worried that there was a subtly broken ring buffer somewhere in the
> source.)

Oh, sry i missread the diff. But it's ok in both ways :)

> > What was your impression? What you would add or change?
>
> My recommendation:
>
> $ sudo updatedb
> $ sudo rm -rf `locate swk`

I would never do that. A part that locate is the weirdest program i have ever seen in unix...such a crappy file indexer. And rm -rf can result on a really desperating situation..and mostly using sudo..which is a really bloated app.. Really. Those two lines make my day.

> I second Uriel's comments.  SWK might be tolerable in an infrequently
> used menu system for a graphical game, but it cannot be made useful for
> much else.

I cant find swk useful in any game. Only as simple frontend for many apps to interact on touchscreens and small devices, and probably on desktop boxes takes some sense to enable my mother to do some basic things..also a mail client, web browser, image viewer... But never in a game..games NEED fancy graphics, and this is not what i try to do.

> The problem is not SWK's lack of functionality, it is the fact that
> SWK's interface cannot encapsulate the complexity needed to implement
> the expected functionality of a modern widget kit:

Why you need to encapsulate such complexity? Can you remove those imposed requeriments from your mind?

> * a movable insertion point in text fields,

This will be added, and its not that complex (maybe 15LOC) just dont blame me to publish a POC. Because i already put that in todo.

> * selection of text using the keyboard and/or mouse,

Same as above

> * placement of the insertion point using the mouse,

Same as above

> * a multi-line text editor that does not need to be run as a separate
>    process,

i never said that

> * support for non-monospaced fonts,

Why do you need that?

> * support for Unicode combining characters,

This is already supported

> * support for right-to-left scripts,

Point this understand dont I.

> * user customization of the color scheme,

Did you read config.h?

> * support for user-selected input methods,

This is about the backend..can you explain more on this?

> * etc.
>
> > I forgot to explain some of the keybindings or features..
> >
> > Use control +/- to increase/decrease font size
>
> Useless bloat.

This will be optional in config.h. Maybe i should buy new glasses, but i still fins this feature useul.

> > control + j/k like tab/shift tab to change focus
>
> I want to use C-k for delete-to-EOL.

You are free to send patch.

> > it supports touchscreens and normal desktops
>
> What do you mean by 'supports'?

Means 'it is supported'. So..you can use swk on a touchscreen without having to mess with invalid input events. This doesnt means multitouch or anything else. It just means touchscreen.

> > scrolling boxes is done by click+drag or mouse wheel
>
> What's a box?  I didn't see any indication in the test programs that
> anything could be scrolled.

Swk_box_newline(-1) // its a macro.

This isnt clear, because isnt defined at all, feel free to propose a better design/name for it.

The thing is that positive newlines are just that, and negative ones open a scrolling area.

> > there is no support for multiline widgets like text area widget
>
> That's not a feature, it's a defect.

Neither of them. Its a TODO.

> > mouse button configuration will be done when we get x11 backend
> > looking for ports to x11,android,w32,osx,iphone...
> >
> > X11 backend can add a widget to embed other x11 apps like tabbed does, so
> > ...it would be a good exercice to try to write a replacdment in swk, or just
> > think on possible apps, design their interfaces correctly and implement them.
> > This will help us to find the requirements.. To know which widgets we need,
> > enhace the layout algorithm, rendering...
> >
> > This step adds another step in the chain.. This is.. We need a guideline to
> > design suckless user interfaces...i have some ideas in mind..but i would
> > prefer to have swk more stable to think on that atm.
>
> You need a definition of 'suckless user interface' before you start
> specifying guidelines for how to produce one.

Yep. User interfaces requires a long list of design guidelines. And we should define new rules for suckless UI apps.

> Here's a draft:
>
>    A suckless user interface is:
>
>    * useful,
>    * usable,
>    * transparent,
>    * either discoverable or well-documented,
>    * reliable,
>    * as simple as possible, and no simpler, and
>    * customizable.

I agree with all those points, but which points do you think swk doesnt follow?

--pancake
Received on Mon May 10 2010 - 08:20:33 UTC