Am Donnerstag, 3. März 2011, 12:05:59 schrieb Łukasz Pankowski:
> Neil Jerram <[email protected]> writes:
> > [email protected] (Łukasz Pankowski) writes:
> >> I made a screenshot for you
> >> http://lupan.zapto.org/slfr/sidle-screenshot.png
> >> it is simply a clock with network and battery status at the bottom.
> >
> > Thanks, that looks nice.
> >
> >> You slide the idle screen with the finger from left to right to unclock
> >> the screen or from up to bottom to suspend it. I often turn gta02 on
> >> just to check the time and immediately slide down to suspend. Or after
> >> using the phone for the moment I also often lock the screen with AUX,
> >> check the time on idle screen and slide down to suspend).
> >>
> >> Missing features:
> >> 1. display date below the time
> >> 2. display missing calls / new messages
> >> 3. distant future: integration with calendar/alarms
> >>
> >> (for example could display today entry from emacs diary file)
> >
> > Those all sound like good ideas. However... the problem is the time it
> > may take to achieve an overall system with the same level of function as
> > the current SHR.
> >
> > I experimented in a vaguely similar way (i.e., I guess, simplicity
> > seeking) a few months ago, with an Emacs-based interface in Debian. The
> > thing that eventually made me give up was discovering how hard it is to
> > integrate some of the basic things that are already integrated in SHR;
> > for example screen locking, suspend/resume, and controlling dimming.
>
> I can imagine two possible paths:
>
> 1. do something from scratch in isolation from SHR -- this would be
> frustrating because you want to have a working system today (or soon)
> and use programs you are working on and you would be in a harry to write
> something.
>
> 2. integrate with SHR, slowly replacing it (elementary apps with minimal
> ones) element by element -- that is what I started to do in a very
> limited spare time. And that is what libphone-ui allows to do due to
> its modular design. (each of idle screen, call window, messages etc may
> be provided by a separate module -- dynamically loaded library; by
> default they are all started from the same shr.so library). I have
> written a module for libphone-ui which runs my sidle replacing the
> default idle screen (actually it calls the shell script which does the
> dirty hack).
That is interesting... libphone-ui is designed to allow that yes. But the
implementation is lacking :-/
#if 0
int i;
for (i = 0 ; i < BACKEND_NO ; i++) {
_phoneui_backend_loop(i);
}
#else
/* FIXME: until we add support for threads, run only one loop */
_phoneui_backend_loop(BACKEND_CALLS);
#endif
is what it does right now, because back then we had problems with multiple
threads running correctly. And the motivation to fix it was not very hight,
because of the lack of other backends ;)
That seems to have changed now and it's time to revisit that multiple threads
problem :-)
>
> I hope to write the full set of minimal (and hopefully suckless) phone
> apps some day but I am not in a hurry, as I do have a usable phone on
> the way, thanks to SHR. I will polish the source and build ipk of sidle
> (may be slightly faster if somebody asks me) but now my priority is to
> fix SHR phone windows to maximize properly under dwm. (I suspect that
> illume is more aggressive in forcing windows/clients to be maximized and
> under dwm those issues are uncovered).
yup, illume forces all windows to be maximized.
>
> Later one could experiment whether using [9p
> protocol](http://libs.suckless.org/libixp) instead of dbus could simplify
> the interaction of the phone apps
> (but it may be that interoperability with rest of the world
> which use dbus would turn out to be more important).
>
> >>> Also, does svkbd do the same kind of fuzzy input thing that the Illume
> >>> keyboard does?
> >>
> >> No, it sends keys as you type them.
> >
> > I really like how the Illume keyboard works, so I'd miss not having
> > that.
>
> Possible to extend svkbd (suckless apps are easily hackable due to the
> short and understandable code), but in this point low priority.
>
> Łukasz
>
> > Neil
>
--
Klaus 'mrmoku' Kurzmann
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel
