Re: [dev] Talk about sane web browsers

[Pinocchio]

On Wed, 09 Sep 2009 04:54:30 -0700, frederic  wrote:


On Wed, 09 Sep 2009 10:06:20 +0200, Anselm R Garbe 
wrote:


2009/9/9 Pinocchio :

I am saying this because even after a lot of marketing muscle and
commercial force, it has been hard for Adobe, Sun and Microsoft to
push
their rendering stacks over HTML + Javascript. Flash is the only thing
which gained major adoption... and the picture might change once HTML
5
comes out.



The Flash strategy is definitely what I have in mind.



I guess the problem would be convincing the 100s of millions of people
to
install our plugin. Much worse than converting web app developers to our
stack. [I have a feeling I didn't quite get your point here...]




If you can attract the developpers, the users will probably follow. The
perfect scenario is when a programmer develops a killer application using
your technology. Users install whatever is required in order to run the
app. It seems to me that convincing a developper to user your platform is
the extremely difficult part. This is where the technology has to be a lot
better in a lot of areas.



Hmmm... I guess doing both doesn't harm anybody :)


Well, before taking the penetration aspect too far -- it is more
important to discuss the actual new web stack first. Key to it is that
it provides benefits wrt the existing web stack in many aspects (like
flash *yuck* or silverlight -- not too sure about silverlight adoption
though), that in itself will drive adoption. (Packaging the new
browser as a plugin for legacy browsers would make a lot of sense
though to drive adoption.)

But what I'm more interested in is this:

- knowing the limitations of HTTP and complexity of HTTP/1.1 compliant
web servers, shouldn't the new web stack rely on a new protocol
instead?


I'm not a specialist, but it seems to me that the only limitation of HTTP
is its stateless-ness, which forces state management at an upper level at
the cost of extra complexity. AFAIK caching mechanisms and
security/encryption are there, but could easily be simpler.
So it looks like it is a secondary issue.



A new protocol would be a good idea. We should probably stick to a subset of 
HTTP/1.1. Can somebody come up with a transport scenario which cannot be 
fulfilled by HTTP/1.1?

I think it is a good idea to keep the transport layer state-less. That cleanly 
separates caching from transport which IMHO is a good thing as applications may 
want to decide what and how to cache data. However, I do think that putting in 
support for a content hash based local cache right at the transport layer would 
be a good idea. By support I really mean that object URIs contain the content 
hash in them so that the browser can check after resolving a URI whether it 
really needs to fetch the content.


- knowing the limitations of nowadays web applications, how should the
content be organized? Should there be a strict separation of
data/content and views? How would a scripting interface look like?


The Web has evolved from simple, static, linked together documents servers
to full-blown applications and two-way communication (FB, twitter etc.).
All this use-cases coexist nowdays.
"separation of date and views" is clearly a variation on the "code/data"
duality. A priori, one should be neutral on this, in order to "perform" in
an average way in all use-cases. IOW, it should suck averagely in all
cases.
As I see it, a simple,static document should be a program that consists
essentially in a few "print" statements of the text, plus some code for
link-buttons and font selection etc. Of course, the scripting language
must be chosen so that it doesn't get too much in the way in this case. A
full blown app would obviously be 90% of code with a few bits of static
text.
However, in this approach the content is mixed with the way it is
displayed; I think the idea must be refined so that a client may extract
the content rather than just displaying it.



I agree whole heartedly. There is no point of separating code and data at the 
browser layer. As I have mentioned earlier, I think a cross platform minimal 
bytecode would be good. I would appreciate feedback on pros and cons of this 
approach.


How would extension points look like?


I'm not sure what you refer to, but one would use the extension mechanism
of the interpreter of the scripting language.



Extensions should be downloaded, cached and run just like the rest of the web app. There 
is little point in separating local extensions and remote "webapps".


What about security to begin with?


This is actually two questions:
- security of the connexion,
- safety of the interpreter. As someone else pointed, The whole thing must
run in a sandbox.



Oh... this is the big hairy mess that would need some thought. I think web 
developers would like cross site code execution + data access. However, at the 
same time the user should be given control over what a website can or cannot 
access. I don't think a lot of this can be made backward

[dev] wmi-11

[Anselm R Garbe]

Hi there,

I plan a new wmi-11 maintenance release, those of you familiar with
WMI or curios about it, please test hg tip:

hg clone http://hg.suckless.org/wmi

Kind regards,
Anselm

Re: [dev] slides with troff (was: Talk about sane web browsers)

[Uriel]

Cool, glad that you found it useful.

Displaying the slides in a minimally sane pdf/ps viewer like page(1)
is also very recommended. Page, at least when running under rio(1) can
easily go into a pseudo-full-screen mode that is perfect for
displaying slides, while it is easy to open an extra windows if you
want to demo stuff...

Enjoy.

uriel

On Wed, Sep 9, 2009 at 8:35 PM, markus schnalke wrote:
> [2009-09-09 04:59] Uriel 
>>
>> Ok, I put this together in five min while sleep deprived, but I think
>> it still should be enough to get you started:
>>
>> http://repo.cat-v.org/troff-slider/
>
> Thanks. I'm so happy that your files finally solved my problem.
>
> The missing piece was:
>
>  | awk '{print} NR==1{print "%%BoundingBox: 0 0 600 450"}'
>
> The macros are quite handy too.
>
>
> ... hello doctools, here I come! :-)
>
>
> meillo
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFKp/Vo6aFpZ+X9qBIRAkAxAJ9OaJZDGbxCe/FmiybeN8ZuJ0SQoACfRujn
> pf1+DkYN5A8DghllaV1LCTE=
> =kuso
> -END PGP SIGNATURE-
>
>

[dev] [surf] 0.1 dist tarball broken

[Ray Kohler]

The surf 0.1 tarball doesn't build. (I'm packing it for Arch AUR.)
There are two problems: the tarball doesn't contain config.def.h ; and
even if it did, there is an extra variable "background" in it that's
not used, and kills the build because of -Werror. I'll work around
these in my PKGBUILD, but it seemed worth sliding the tag for.

[dev] Sizes of the Heirloom project programs

[markus schnalke]

FYI

http://tmp.marmaro.de/heirloom-sloccount.txt


meillo


signature.asc
Description: Digital signature

[dev] [OT] SLOC-counters, take this!

[Antoni Grzymala]

All the mad SLOC-counters, see this:

http://pouet.net/prod.php?which=53816

(No, it doesn't run very well under dosbox.)

-- 
[a]

Re: [dev] [surf] 0.1 dist tarball broken

[Enno Boland (Gottox)]

Thanks (really need a release script).
fixed in 0.1.2

2009/9/10 Ray Kohler :
> The surf 0.1 tarball doesn't build. (I'm packing it for Arch AUR.)
> There are two problems: the tarball doesn't contain config.def.h ; and
> even if it did, there is an extra variable "background" in it that's
> not used, and kills the build because of -Werror. I'll work around
> these in my PKGBUILD, but it seemed worth sliding the tag for.
>
>



-- 
http://gnuffy.chaotika.org - Real Community Distro

[dev] [surf] Speed is awesome

[Andrew Antle]

I just wanted to say that surf seems much faster at loading and
rendering pages with this latest pull. It's sweet! Cheers to Enno
and all other contributors.
-- 
Andrew Antle

[dev][surf] browser identification changed?

[Lorenzo Bolla]

with the latest pull, surf is identified as the awfully old:Netscape
Navigator
with 40-bit encryption (International)
whereas, before it, it was identified as:
Apple Safari (531.2+)
with 128-bit encryption (International)
For this reason, webapp like GMail complain...
Why did it change?

Re: [dev][surf] browser identification changed?

[Lorenzo Bolla]

Alright, I'll answer myself.
surf.c sets "user-agent" to "surf" that is evidently not recognized by those
websites.

I wonder why those websites use these dirty tricks...
L.

On Fri, Sep 11, 2009 at 10:02 AM, Lorenzo Bolla  wrote:

> with the latest pull, surf is identified as the awfully old:Netscape
> Navigator
> with 40-bit encryption (International)
> whereas, before it, it was identified as:
> Apple Safari (531.2+)
> with 128-bit encryption (International)
> For this reason, webapp like GMail complain...
> Why did it change?
>

Re: [dev] [surf] Speed is awesome

[Enno Boland (Gottox)]

Well, honestly, I only programmed an interface to the webkit engine.
Blame them for the speed.

2009/9/10 Andrew Antle :
> I just wanted to say that surf seems much faster at loading and
> rendering pages with this latest pull. It's sweet! Cheers to Enno
> and all other contributors.
> --
> Andrew Antle
> 
> 
>
>



-- 
http://gnuffy.chaotika.org - Real Community Distro

Re: [dev] [surf] patches: configurable file locations, bookmark writer, history writer

[Mikael Schönenberg]

On Wed, Sep 9, 2009 at 15:31, Ray Kohler wrote:
> The difficulty with using xprop to read and write surf's URL is that
> even though I have the XID when the session starts, there's a risk
> that it changes. Links may open themselves in new windows, or the user
> might choose to do it with webkit's context menu. It seems
> uncomfortable to require the user of a bookmark managing system to do
> some manual step to indicate which window their action applies to, so
> I chose to let the window initiate the action, as in these patches,
> which resolves the ambiguity.

Presumably, it's the currently focused window when the user creates
the bookmark. Or is that too naive?

-- 
Mikael Schönenberg

Re: [dev] [OT] SLOC-counters, take this!

[Benoit T]

On Fri, Sep 11, 2009 at 09:43:25AM +0200, Antoni Grzymala wrote:
> All the mad SLOC-counters, see this:
> 
> http://pouet.net/prod.php?which=53816

greatness in 256 bytes :)
included asm source file is 256 lines with comments that do not even
look artificial. now that's taste.

> (No, it doesn't run very well under dosbox.)

it runs very slow under dosbox or qemu on my 4-year old pentium M, but
fine under dosemu (dosemu will require temporarily setting
/proc/sys/vm/mmap_min_addr set to 0, though).
also the windows version works fine under wine.

cheers

-- 
Benoit Triquet 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

[dev] [surf] surf-0.1

[Enno Boland (Gottox)]

Hi there!

This is the first official release of surf, a minimal Webkit/GTK based browser.
You can download it here:

http://dl.suckless.org/surf/surf-0.1.tar.gz

Changelog: http://hg.suckless.org/surf

Please test try it out and give feedback.

regards
Gottox
-- 
http://gnuffy.chaotika.org - Real Community Distro

Re: [dev] [surf] Speed is awesome

[hiro]

This is ridiculous.
Also speed is really no drug I would ever recommend, it's far from awesome.

asskisses,
hiro

On Thu, Sep 10, 2009 at 6:22 PM, Andrew Antle wrote:
> I just wanted to say that surf seems much faster at loading and
> rendering pages with this latest pull. It's sweet! Cheers to Enno
> and all other contributors.
> --
> Andrew Antle
> 
> 
>
>

Re: [dev] [surf] Speed is awesome

[Andrew Antle]

On Fri, Sep 11, 2009 at 12:21:25PM +0200, hiro wrote:
> This is ridiculous.
> Also speed is really no drug I would ever recommend, it's far from awesome.
> 
> asskisses,
> hiro
> 
> On Thu, Sep 10, 2009 at 6:22 PM, Andrew Antle wrote:
> > I just wanted to say that surf seems much faster at loading and
> > rendering pages with this latest pull. It's sweet! Cheers to Enno
> > and all other contributors.
> > --

Your wit really is amazing.

Andrew Antle

Re: [dev] [dwm] Fibonacci spiral and Movestack patches for dwm 5.6.1

[Jacob Todd]

On Wed, Sep 09, 2009 at 07:37:22PM +0200, Mate Nagy wrote:
> > The movestack patch allows you to swap the selected client with the client
> > before or after it (a clone of the Xmonad mod-shift-j and mod-shift-k
> > functionality) -
> > http://www.aplusbi.com/projects/dwm/dwm-5.6.1-movestack.diff
>  this exists in a few instances already, apparently many people like it :)
>  for instance: http://dwm.suckless.org/patches/push
>  see also: http://dwm.suckless.org/patches/attachabove
 
Attachabove doesn't move anything, it just create's the new client above the
stack if you're focused on it.

> Regards,
>  Mate
> 

-- 
Jake Todd
// If it isn't broke, tweak it!


pgpEXppvRw4gy.pgp
Description: PGP signature

Re: [dev] [surf] Speed is awesome

[hiro]

Thanks for pointing this out, I knew I had a hidden talent somewhere.

On Fri, Sep 11, 2009 at 12:37 PM, Andrew Antle wrote:
> On Fri, Sep 11, 2009 at 12:21:25PM +0200, hiro wrote:
>> This is ridiculous.
>> Also speed is really no drug I would ever recommend, it's far from awesome.
>>
>> asskisses,
>> hiro
>>
>> On Thu, Sep 10, 2009 at 6:22 PM, Andrew Antle wrote:
>> > I just wanted to say that surf seems much faster at loading and
>> > rendering pages with this latest pull. It's sweet! Cheers to Enno
>> > and all other contributors.
>> > --
>
> Your wit really is amazing.
>
> Andrew Antle
>
>

Re: [dev] [dwm] Fibonacci spiral and Movestack patches for dwm 5.6.1

[Jacob Todd]

On Wed, Sep 09, 2009 at 12:17:51PM -0400, Niki Yoshiuchi wrote:
> I finally got around to updating my dwm patches for 5.6.1.  I will add them
> to the site later today but for now, here they are:
> 
> The Fibonacci spiral patch offers a new layout that arranges the clients in
> a spiral - http://www.aplusbi.com/projects/dwm/dwm-5.6.1-fibonacci.diff
> 
> The movestack patch allows you to swap the selected client with the client
> before or after it (a clone of the Xmonad mod-shift-j and mod-shift-k
> functionality) -
> http://www.aplusbi.com/projects/dwm/dwm-5.6.1-movestack.diff
> 
> -Niki Yoshiuchi

Thanks for updating these, Niki.
-- 
Jake Todd
// If it isn't broke, tweak it!


pgpeIKQHyslmG.pgp
Description: PGP signature

Re: [dev] [surf] Was: Speed is awesome Now: I'm a fucking morose pedant

[Andrew Antle]

On Fri, Sep 11, 2009 at 01:07:39PM +0200, hiro wrote:
> Thanks for pointing this out, I knew I had a hidden talent somewhere.
> 
> On Fri, Sep 11, 2009 at 12:37 PM, Andrew Antle wrote:
> > On Fri, Sep 11, 2009 at 12:21:25PM +0200, hiro wrote:
> >> This is ridiculous.
> >> Also speed is really no drug I would ever recommend, it's far from awesome.
> >>
> >> asskisses,
> >> hiro
> >>
> >> On Thu, Sep 10, 2009 at 6:22 PM, Andrew Antle 
> >> wrote:
> >> > I just wanted to say that surf seems much faster at loading and
> >> > rendering pages with this latest pull. It's sweet! Cheers to Enno
> >> > and all other contributors.
> >> > --
> >
> > Your wit really is amazing.
> >

Please, lamb sandwich, feel free to share with the class your
experiences with amphetamines.

Attempting to commend someone for a job well done is so lame.

Is there a fucking bridge around here? Something smells awful.

Re: [dev] [surf] patches: configurable file locations, bookmark writer, history writer

[Ray Kohler]

2009/9/9 Mikael Schönenberg :
> On Wed, Sep 9, 2009 at 15:31, Ray Kohler wrote:
>> The difficulty with using xprop to read and write surf's URL is that
>> even though I have the XID when the session starts, there's a risk
>> that it changes. Links may open themselves in new windows, or the user
>> might choose to do it with webkit's context menu. It seems
>> uncomfortable to require the user of a bookmark managing system to do
>> some manual step to indicate which window their action applies to, so
>> I chose to let the window initiate the action, as in these patches,
>> which resolves the ambiguity.
>
> Presumably, it's the currently focused window when the user creates
> the bookmark. Or is that too naive?

Depending on how the user calls their bookmark management frontend, it
may itself steal the focus from the browser.

Re: [dev] [surf] surf-0.1

[Uriel]

On Thu, Sep 10, 2009 at 1:23 PM, Enno Boland (Gottox)  wrote:
> Hi there!
>
> This is the first official release of surf,
> a minimal Webkit/GTK based browser.

Triple oxymoron.

uriel



> You can download it here:
>
> http://dl.suckless.org/surf/surf-0.1.tar.gz
>
> Changelog: http://hg.suckless.org/surf
>
> Please test try it out and give feedback.
>
> regards
> Gottox
> --
> http://gnuffy.chaotika.org - Real Community Distro
>
>

Re: [dev] [surf] surf-0.1

[Ryan R]

surf-0.1.tar.gz is missing config.def.h

On 9/11/09, Uriel  wrote:
> On Thu, Sep 10, 2009 at 1:23 PM, Enno Boland (Gottox) 
> wrote:
>> Hi there!
>>
>> This is the first official release of surf,
>> a minimal Webkit/GTK based browser.
>
> Triple oxymoron.
>
> uriel
>
>
>
>> You can download it here:
>>
>> http://dl.suckless.org/surf/surf-0.1.tar.gz
>>
>> Changelog: http://hg.suckless.org/surf
>>
>> Please test try it out and give feedback.
>>
>> regards
>> Gottox
>> --
>> http://gnuffy.chaotika.org - Real Community Distro
>>
>>
>
>

Re: [dev] Talk about sane web browsers

[Pinocchio]

On Wed, 09 Sep 2009 00:36:17 -0700, Anselm R Garbe  wrote:


2009/9/9 pancake :

There is also "neko". The problem is that I don't see the need of clientside
scripting. A clean design should split presentation and data. And having a
templating language for merging them into a canvas. So not having the
possibility to create infinite loops, eat the CPU, etc.. The web should be
safe and simple. If you want to run something more complex you should use a
sandbox or something able to do static code analysis in a way that ensures
me that the running code is no dangerous.


Oh, are you saying you found a way to decide the halting problem?



No... but there are ways to contain malicious execution.

I think client side scripting is required to avoid round-trips to the server for simple 
operations (changing views for eg.). Also, once the decision is made on implementing a 
"full" language, I would _not_ like the base UI abstraction to be declarative 
(mainly from a minimalism point of view).

As an extreme example I was thinking of running an arbitrary executable downloaded from 
the "website" and running it in a process which is allowed to do only IPC to 
its parent process. The parent process controls CPU and memory resources of the client. 
For everything else the client process does IPC... this includes accessing APIs to render 
the canvas and access the network. It may be a good idea to settle on a cross-platform 
bytecode format for the same... there are quite a few to choose from.

It would be really nice if we could make it scripting language independent. People should 
have a choice to use Lua, Neko, Io or whatever they like to build a "webapp" 
and access the core runtime (through IPC).

--
Pinocchio

[dev] [wmii] upcoming release and fullscreen bugs

[Thomas Dahms]

Hi all,

Kris requested feedback before releasing wmii 3.9, so here is mine:

- The fullscreen bugs (#22 and #68) should probably be fixed before a  
release. #22 can completely destroy your column layout when toggling  
fullscreen, while #68 may make clients invisible. A release should not  
have such severe bugs.


- With the new alternative Python wmiirc and probably coming more in the  
future, I wonder if it still makes sense to keep the logic to choose  
rc.wmii over wmiirc when rc is found. Personally, I would prefer less  
clutter and choose which wmiirc I put in ~/.wmii-hg/ without having wmii  
think for me depending on the installed software. Just let rc.wmii be an  
alternative wmiirc like the Python one with nothing rc-related installed  
in /etc by default.


- Switch from ~/.wmii-hg to ~/.wmii.

Just my thoughts.

Thomas

Re: [dev] slides with troff (was: Talk about sane web browsers)

[Wu, Yue]

On Thu, 10 Sep 2009 02:35:20 +0800, markus schnalke   
wrote:



[2009-09-09 04:59] Uriel 


Ok, I put this together in five min while sleep deprived, but I think
it still should be enough to get you started:

http://repo.cat-v.org/troff-slider/


Thanks. I'm so happy that your files finally solved my problem.

The missing piece was:

  | awk '{print} NR==1{print "%%BoundingBox: 0 0 600 450"}'

The macros are quite handy too.


... hello doctools, here I come! :-)



Whether it supports multi-languages like Chinese? If so, then I think  
maybe I should get a close look at it.



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [dev] slides with troff (was: Talk about sane web browsers)

[markus schnalke]

[2009-09-10 12:38] Wu, Yue 
> On Thu, 10 Sep 2009 02:35:20 +0800, markus schnalke   
> wrote:
> >
> >... hello doctools, here I come! :-)
> 
> Whether it supports multi-languages like Chinese? If so, then I think  
> maybe I should get a close look at it.

It supports UTF8.


meillo


signature.asc
Description: Digital signature

[dev] Re: dwm: suckless way to monitor work hours

[Marcin Cieslak]

Dnia 07.09.2009 Niklas Koponen  napisał/a:
> On Sat, Sep 5, 2009 at 11:27 PM, Preben Randhol wrote:
>> On Tue, 1 Sep 2009 10:07:47 +0300
>> Niklas Koponen  wrote:
>>
>>> My plan is to take a snaphot of the root window at certain intervals
>>> if there has been some mouse or keyboard activity. I also record the
>>> amount of activity. Then I store the information and at the end of the
>>> month I just generate a report based on this information.
>>
>> Any reason you need something so complicated? You only get paid by
>> keyboard/mouse activity?
>
> Yes. I do java development.
>
> Actually I'm so lazy to mark down my hours when I do the work, so that
> after a month it is also impossible to figure out if I had a day off
> or if I did only a half day and so on.

There is one utility that does something similar, although for a
different purpose: xwrits (http://www.lcdf.org/xwrits/) monitors
keyboard / mouse activity to force you to break not to kill your
hands. It has some interesting functions like accummulating breaks
you take anyway (going to drink sth., play with the kids etc.) 
not to nag you every straight hour. 

Looking at the source of xwrits it's quite pleasant and suckless,
so maybe it can be hacked up to provide a report to give you your
activity times.

This could be combined with plain old UNIX accounting (ac(8) on BSD
systems) to accumulate some resource types over time for the very
purpose to bill their usage. Since FreeBSD sends a monthly login
report to me every month I actually see how long my laptop was on.
Probably it could be hacked to track actual X activity time (as
defined by xwrits for example) - the only thing you need is to
manipulate utmp and wtmp - and voila - your timesheet is ready.
You might only need to switch users (login names) for different
projects. Or switch to OpenSolaris and use project management
features there.

(Coming back after dwm/wmii->dev migration, still confused, maybe 
the old way was not that bad - somehow I have the feeling that 
mailing list manager is slow && the newsgroup subscription 
remarks provided by GMANE are not up to date)

-- 
  << Marcin Cieslak // sa...@saper.info >>

Re: [dev] [wmii] upcoming release and fullscreen bugs

[Suraj Kurapati]

On Fri, Sep 11, 2009 at 12:31 PM, Thomas Dahms  wrote:
> - Switch from ~/.wmii-hg to ~/.wmii.

+1

Re: [dev] [wmii] upcoming release and fullscreen bugs

[Kris Maglione]

On Fri, Sep 11, 2009 at 09:31:55PM +0200, Thomas Dahms wrote:
- The fullscreen bugs (#22 and #68) should probably be fixed before a  
release. #22 can completely destroy your column layout when toggling  
fullscreen, while #68 may make clients invisible. A release should not  
have such severe bugs.


I agree. I've added milestone tags to those issues.

- With the new alternative Python wmiirc and probably coming more in the  
future, I wonder if it still makes sense to keep the logic to choose  
rc.wmii over wmiirc when rc is found. Personally, I would prefer less  
clutter and choose which wmiirc I put in ~/.wmii-hg/ without having wmii  
think for me depending on the installed software. Just let rc.wmii be an  
alternative wmiirc like the Python one with nothing rc-related installed  
in /etc by default.


Yes, that's the plan. The rc version will move to 
alternative_wmiircs/plan9port in the next alpha.



- Switch from ~/.wmii-hg to ~/.wmii.


That's already the case in the alpha bundles.

--
Kris Maglione

The pessimist complains about the wind; the optimist expects it to
change; the realist adjusts the sails.
--William Arthur Ward

Re: [dev] slides with troff (was: Talk about sane web browsers)

[Uriel]

It supports UTF-8, that is all anyone sane should need.

uriel

On Thu, Sep 10, 2009 at 6:38 AM, Wu, Yue  wrote:
> On Thu, 10 Sep 2009 02:35:20 +0800, markus schnalke 
> wrote:
>
>> [2009-09-09 04:59] Uriel 
>>>
>>> Ok, I put this together in five min while sleep deprived, but I think
>>> it still should be enough to get you started:
>>>
>>> http://repo.cat-v.org/troff-slider/
>>
>> Thanks. I'm so happy that your files finally solved my problem.
>>
>> The missing piece was:
>>
>>  | awk '{print} NR==1{print "%%BoundingBox: 0 0 600 450"}'
>>
>> The macros are quite handy too.
>>
>>
>> ... hello doctools, here I come! :-)
>>
>
> Whether it supports multi-languages like Chinese? If so, then I think maybe
> I should get a close look at it.
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>

Re: [dev] [wmii] upcoming release and fullscreen bugs

[KIMURA Masaru]

HAI

2009/9/12 Kris Maglione :
>> - Switch from ~/.wmii-hg to ~/.wmii.
>
> That's already the case in the alpha bundles.

Nope.
sh version still uses ~/wmii-hg here on hg2483.

THX

Re: [dev] [wmii] upcoming release and fullscreen bugs

[Kris Maglione]

On Sat, Sep 12, 2009 at 11:27:09AM +0900, KIMURA Masaru wrote:

HAI


That's already the case in the alpha bundles.


Nope.
sh version still uses ~/wmii-hg here on hg2483.


In hg and the snapshot bundles, yes, it's still ~/.wmii-hg. In the 
alpha tarballs, it's ~/.wmii


--
Kris Maglione

Beware of bugs in the above code; I have only proved it correct, not
tried it.
--Donald Knuth

Re: [dev] [wmii] upcoming release and fullscreen bugs

[KIMURA Masaru]

2009/9/12 Kris Maglione :
> On Sat, Sep 12, 2009 at 11:27:09AM +0900, KIMURA Masaru wrote:
>>
>> HAI
>>
>>> That's already the case in the alpha bundles.
>>
>> Nope.
>> sh version still uses ~/wmii-hg here on hg2483.
>
> In hg and the snapshot bundles, yes, it's still ~/.wmii-hg. In the alpha
> tarballs, it's ~/.wmii

ok, then why does hg's still keep CONFVERSION=-hg? CONFVERSION looks
like bit redundant kludge for me b/c wmii is not so {for,back}ward
compatible in my exp.

Re: [dev] [wmii] upcoming release and fullscreen bugs

[Kris Maglione]

On Sat, Sep 12, 2009 at 11:49:05AM +0900, KIMURA Masaru wrote:

In hg and the snapshot bundles, yes, it's still ~/.wmii-hg. In the alpha
tarballs, it's ~/.wmii


ok, then why does hg's still keep CONFVERSION=-hg? CONFVERSION looks
like bit redundant kludge for me b/c wmii is not so {for,back}ward
compatible in my exp.


That's exactly the point. It's not so far forward and backward 
compatible. The hg repo and the snapshots use .wmii-hg because 
they're not always compatible with the stable release, and it's 
nice to be able to test hg without having to swap your 
configuration back and forth of dump your stable release 
entirely. The hg repo and the snapshots will always use 
.wmii-hg; the release and snapshot tarballs come with slightly 
modified config.mk and mk/wmii.mk files.


--
Kris Maglione

It is difficult to get a man to understand something when his salary
depends on his not understanding it.
--Upton Sinclair

Re: [dev] [wmii] upcoming release and fullscreen bugs

[KIMURA Masaru]

2009/9/12 Kris Maglione :
> On Sat, Sep 12, 2009 at 11:49:05AM +0900, KIMURA Masaru wrote:
>>>
>>> In hg and the snapshot bundles, yes, it's still ~/.wmii-hg. In the alpha
>>> tarballs, it's ~/.wmii
>>
>> ok, then why does hg's still keep CONFVERSION=-hg? CONFVERSION looks
>> like bit redundant kludge for me b/c wmii is not so {for,back}ward
>> compatible in my exp.
>
> That's exactly the point. It's not so far forward and backward compatible.
> The hg repo and the snapshots use .wmii-hg because they're not always
> compatible with the stable release, and it's nice to be able to test hg
> without having to swap your configuration back and forth of dump your stable
> release entirely. The hg repo and the snapshots will always use .wmii-hg;
> the release and snapshot tarballs come with slightly modified config.mk and
> mk/wmii.mk files.

ACK

Re: [dev] slides with troff (was: Talk about sane web browsers)

[Wu, Yue]

On Sat, 12 Sep 2009 06:50:03 +0800, Uriel  wrote:


It supports UTF-8, that is all anyone sane should need.

uriel



Nice, thank you for info. I will look at it, hoping it can be used on  
windows as well.



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/