Re: snap to grid feature
- From: Reginald Melchisedek Poyau <melchisedek earthlink net>
- To: Ali Akcaagac <ali akcaagac stud fh-wilhelmshaven de>
- Cc: nautilus-list gnome org
- Subject: Re: snap to grid feature
- Date: 12 Aug 2002 15:34:16 -0400
On Wed, 2002-07-17 at 08:26, Ali Akcaagac wrote:
Hello,
The snap to grid algorithm could be made simpler.
The desktop viewable area would be divide into cells grid with
cell size Cx by Cy.
desktop viewable would not include the panels. Four desktop padding
values could take care of this top, bottom, left, and right.
Standard Icon size:
Cells would also have padding values
Cpx == cell horizontal padding
Cpy == cell vertical padding
Icon position (Px, Py) as calculated as follows:
Px = Px/Cx + Cpx, Py = Py/Cy + Cpy
Cell viewable horizontal length = Cx - 2 * Cpx
Cell viewable vertical length = Cy - 2 * Cpy
Icons can then be scaled to fit into cells viewable erea if they not
substentially bigger then cells viewable area.
I also think that it would be a good idea to divide cells into two
area. One area for labels, and one for the actual icon. Area for
labels should be big enough to fit about four lines text.
Case not handle:
1) how do icons rearrange themselves when panels get resized/created or
user switches desktop resolution. * see next case as this is partially
related
2) How much scaling should nautilus do to fit new icons if there are not
enough empty grids to hold new icons; like a user dumping an archive to
desktop or changing resolution to lower one.
I dont think scaling solution is enough, especially for file operations
like copy/move and unarchiving to desktop.
?
Arbitrary icon size: This will complicate matters even further
* I am not even sure if the spec for icons allows for arbitrary icon
sizes.
If icons are substentially bigger in either dimension (x,y) then
respective adjacent cells would be use until the combined cells viewable
length is close enough to icon's length in that particular dimension.
The icon would then be scale to fit into that new combined cell viewable
area.
case not handle:
adjacent cell is already occupied.
> hi,
>
> since yesterday evening i have the idea of doing some 'snap to grid'
> feature so i can adjust the icons on my desktop. the first idea i had
> was to do it in offline mode as many people are doing right now. that is
> quitting gnome, grabbing the prefered editor and change the values in
> the xml file to adjust the icons. then load up gnome again and the icons
> are somehow nicelely grid'ed.
>
> after keeping all this ideas in head i thought that it may be easier to
> solve this stuff in the nautilus code itself. after investigating into
> the nautilus code (which really beats me, since i never looked into
> that) i finally found out about the 2 main files that seem to be
> responsible for layouting stuff.
>
> a) src/file-manager/fm-icon-view.c
>
> which seems to call up the callback and some other stuff that i need to
> figure out first.
>
> b) nautilus/libnautilus-private/nautilus-iconcontainer.c
>
> which has 90% of the code done that are imo needed to make a snap to
> grid function. it has the x/y value of the icon, the dimension of the
> whole desktop (container) etc. everything needed to do the grid
> function. i have also figured out a simple algorithm howto sort the
> icons on the desktop which globally looks like this:
>
> - grab the 1st icon,
> - look at the x/y position
>
> - grab x position,
> - start counting from 0/0 and add the pad value (which seems to be the
> default icon <-> icon pad and add it to that until you reach the
> leftmost (min value) of x, save that value same for the rightmost (max
> value). now calculate (x-min value) and (x-max value) now compare both
> results and which one is more little grid it to either min value or
> max value.
>
> example:
>
> pad = 64
> icon x = 1112
>
> 17 * 64 = 1088
>
> ---- icon is here between these 2 values
>
> 18 * 64 = 1152
>
> 1088 - 1112 = |24|
> 1152 - 1112 = |40|
>
> so the first resulting value is more little than the second one so we
> grid this icon's x to 1088
>
> - same we do with y
>
> we also make sure that we don't bound the icon out of it's maximal
> window border that is if the desktop x is 1152 maximal then we cant grid
> the icon over that value.
>
> the theoretics is quite easy if you don't count the scalable stuff into
> this and go with the predefined padding values inside nautilus.
>
> but the problem for me is, nautilus right now is a tad overhelming for
> me and i need some advises howto go through this procedure. i would be
> really happy and glad to see (anyhow) nautilus supporting snap to grid
> one day.
>
> help, comments, advice all welcome.....
>
> --
> Name....: Ali Akcaagac
> Status..: Student Of Computer & Economic Science
> E-Mail..: mailto:ali akcaagac stud fh-wilhelmshaven de
> WWW.....: http://www.fh-wilhelmshaven.de/~akcaagaa
>
> --
> nautilus-list mailing list
> nautilus-list gnome org
> http://mail.gnome.org/mailman/listinfo/nautilus-list
--
"There has grown in the minds of certain groups in this country the
idea that just because
a man or corporation has made a profit out of the public for a number of
years, the
government and the courts are charged with guaranteeing such profit in
the future, even in
the face of changing circumstances and contrary to public interest. This
strange doctrine
is supported by neither statue or common law. Neither corporations or
individuals have the
right to come into court and ask that the clock of history be stopped,
or turned back."
-Robert Heinlein, Life Line, 1939
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]