proposal to re-work the welcome page

Thomas Friedrichsmeier thomas.friedrichsmeier at kdemail.net
Wed Apr 20 14:27:32 BST 2022


Hi,

I've merged what I have so far into master, so you can have a look.
Some links are still missing / not yet implemented, but I it is a first
mockup, and the part about recent files is functional, already.

So - what do you think? What should we add / remove / improve?

Am Thu, 07 Apr 2022 13:04:35 +0200
schrieb meik michalke <meik.michalke at uni-duesseldorf.de>:
> > _Possibly_ also a list of data.frames in the globalenv(), aka "My
> > data in this workspace"?  
> 
> very useful for people working with data frames. could this probably
> turn into an issue for largely crowded workspaces with loads of data
> frames lying around? i for once often collect those in a list, then i
> wouldn't see them here.

I left this out for now, but I did add a placeholder for "New
data.frame()". I think that's still an important feature for first time
users. So far it is covered by the "Startup dialog", but I think that
one will now be obsolete (and one dialog less to pop up on first start
is a good thing).

[...]

> if each of the sections on this dashboard page were like a <div> with
> an id, it should be easy to make the layout customizable, either with
> defaults in the global configuration or on the page itself (similar
> to the TOC in results), with show/hide buttons for each part.

The sections are separate <div>s, now, and the <body> of the welcome
page has gained an id as well, so it can be special-cased in the CSS
file.

I added an initial layout based on that, but I certainly wouldn't
mind somebody improving it. (Hints to the motivated volunteer: For the
effective HTML source of the start page, look inside your /tmp-folder,
while viewing the page. You'll find the current version of the CSS file
linked in there.)

> can we perhaps re-use the new output page mechanism here? i.e., treat
> the dashboard like a special kind of output file with a fixed
> location? it would then have to be recreated on certain events, so it
> would have to be less dynamic by itself, but a rather static page
> that gets rewritten and reloaded from time to time, and only when
> it's active.

The page is recreated on some events (when the recent files lists
change, ATM). All of that happens in the frontend, however (R would not
even know about a new script file, for instance), so the implementation
actually ended up rather different, as just a few additions to the
current rendering of rkward help pages.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20220420/6a9b4f6b/attachment.sig>


More information about the rkward-devel mailing list