Menu
▾
▴
#352 Squirrelmail 1.4.3 (stable) with no frames
Here's my patch to get rid of those damn frames in SM.
The patch is made against latest stable version (1.4.3a
at the moment). Please note that this version contain
NO folder tree. The folder navigation is done using
plain SELECT gadget. Practically it makes no difference
to you as user, but if you used to use some plugins
that 'docked' in the folder list pane - they are gone.
Logged In: YES
user_id=69131
How to apply the patch:
Get the 1.4.3a official archive. Unpack. Get the patch
archive. Unpack. Enter the "squirrelmail-1.4.3a" directory
and use "patch -p1 <patchfile.patch"
Logged In: NO
While this patch may work for people with 1.4.3a (but it
looks like you missed some things), I suggest that you keep
an eye on the development branch of the SquirrelMail code,
where there is already frameless functionality built in.
This is a list of things to consider as alternatives and
problems with this patch from the SquirrelMail Users mailing
list by Tomas Kuliavas:
a) see jump_to_folder plugin. You can use it instead
modifying sm source
directly.
b) i think, you missed left_main links in folder management
option pages.
Links show up when you create new folder or change folder
structure.
c) some people have different opinion about frames. there is
no need to
shout (capital letters usually mean that) or use some
specific words
together with word "frames".
d)
http://cvs.sf.net/viewcvs.py/squirrelmail/squirrelmail/?only_with_tag=SM_Devel_NoFrames
Logged In: YES
user_id=69131
Yes, it's intended for 1.4.3a users. It's intentional as I
mostly wanted to those changes for my production use hence
my changes in stable release only. As for missing things -
it may always happen - let me know if you trace anything
that needs correction.
a) It won't fully solve the issue, since plugin won't be
i.e. when user is playing with settings. And if so, I'd
prefer not to rely on external code if I need to modify
source code anyway.
b) Thanks for spotting that. Patch 02 corrects that ommision.
c) Some people usually got own opinions, some are even
opposite to yours and that's nothing new I think. However if
you think I'm shouting just because of "FRAMELESS" being
capitalised may be either internet newbie or simply
hypersensitive. Even you like frames in SM you should sleep
well no matter how it's written ;)
d) Thanks, but that's not what I fully wanted. Getting rid
of frames was one goal but I also wanted to gain some
display space. That's why I wipped folder tree out instead
of attempting to reconstruct it in frameless enviroment.
Patch to make SM 1.4.3a completely frameless
Logged In: NO
>>>a) see jump_to_folder plugin. You can use it instead
modifying sm source
>>>>>> directly.
>>
>>>>
>>>> It won't fully solve the issue, since plugin won't be
>>>> i.e. when user is playing with settings. And if so, I'd
prefer not to rely on
>>>> external code if I need to modify source code anyway.
>
>>
>> plugin can be controled by end user, but controls can
also be disabled by admin.
>> SquirrelMail uses modular interface and selection box
that you want
>> to add can be implemented with existing squirrelmail
hooks. I suspect that you can
>> also remove frames with help of some hooks too. if
preview_pane plugin manages to
>> add extra frame, then some other plug might be able
remove it.
>>
>> if you disable ----
>>
$squirrelmail_plugin_hooks['options_folder_inside']['jump_to_folder']
=
>> 'jump_to_folder_options';
>> ----
>> in plugins/jump_to_folder/setup.php, user options are
removed.
>>
>> If you disable
>> ----
>> if (!isset($jump_to_folder_show_mailbox) ||
!$jump_to_folder_show_mailbox) return;
>> ----
>> in jump_to_folder_on_menu() function, selection box will
be always displayed.
>>
>> read doc/plugins.txt and try to use existing options
before you start changing
>> squirrelmail core scripts.
>>
I would also like to point out that the first version of
the frameless SM that the
CVS Branch is based was actually plugin based, with a few
minor changes to SM to
add the necessary hooks. So it can definitely be done via a
plugin with only
minor changes to the core. Just browsing through the patch,
it appears that it
just strips out everything to do with frames, instead of
allowing a user or admin
the option to have it one way or the other, or both.
Everyone has a way they
perfer, and they should be free to make that choice (as the
CVS Branch allows). I
personally don't mind frames, I like the fact that I don't
have to reload the
folder list everytime I click something on the page, but I
also respect other
peoples choices too, so thus my branch gives them the option
to "Have it your
way". As far as doing away with the folder list. Some
people might like it, and
again, some people may not, so an option should probably be
put in there for that
too. I personally can not live without my folder list. I
have 28 folders which
mail is filtered into, 12 of them are mailing lists. I
would not like to have to
browse to every single one of them inorder to see if I have
new messages, with the
folder list, I can just look and with a single glance see
that 2 of my lists have
new messages, and that I also have a message from my brother.
I guess it all boils down to one thing, choice. No one
would be happy with just
one way to do things, we have to cater to whims of everyone
else. Some people
bicker because we don't have noframes support, if we moved
to a complete noframes
version, people would bicker because they liked frames.
Some people would want to
remove the folder list, but once removed, people (including
me) would complain
because now checking their email becomes a chore. As a
community based group, we
have to strive to find a balance that everyone would be
happy with, and the
simplest way to do that is to allows the admin/users to
decide on their own
preference.
As it is now, I can not see this patch ever being accepted
into the SM core, it
offers no choice. Also the whole reason that the CVS branch
version is based on
Devel is because most people running 1.4.X run it because it
is the Stable branch.
The code has been tested, and retested to ensure that it is
not borked. I can't
see many of these people applying a major patch to a already
stable branch, that
kinda defeats the purpose. If the SM developers were to
consider this patch, it
means we would have to convert it to work with Devel, since
that is where it would
be applied (only bug fixes in Stable branch), and then we
would have to completely
rewrite it to give the users a choice.
I do thank you for your effort and the work you have put
into the patch. I am
sure that there are several people that will make use of it,
and will be very
happy with it. But as a developer, I have to look at the
whole picture, and I can
see that without lots of changes, this patch does not go in
the direction that I
believe that SM is heading. But don't let this discourage
your efforts, your work
and time is appreciated. I am hoping that we can combine
your work, with the work
that we have already put into the seperate CVS branch, and
meet on a common
ground. There is no reason to reinvent the wheel is alot of
the work has already
been done. All that really needs to be done, is add an
option in the CVS branch
to completely remove the folder list, plus a few other minor
right to left issues
(for Hebrew, ect..).
If anyone else has any comments on this, I would be gald
to hear them. I do feel
that it is about time we start work on the noframes support
in SM again. But then
we get into the whole templates debate also. Once templates
are implemented, the
noframes support will be done completely through them, so
should we even bother
with it now (and have to remove it all later), or focus on
templating SM, which is
a more pressing goal...
Jimmy
Logged In: NO
>>>a) see jump_to_folder plugin. You can use it instead
modifying sm source
>>>>>> directly.
>>
>>>>
>>>> It won't fully solve the issue, since plugin won't be
>>>> i.e. when user is playing with settings. And if so, I'd
prefer not to rely on
>>>> external code if I need to modify source code anyway.
>
>>
>> plugin can be controled by end user, but controls can
also be disabled by admin.
>> SquirrelMail uses modular interface and selection box
that you want
>> to add can be implemented with existing squirrelmail
hooks. I suspect that you can
>> also remove frames with help of some hooks too. if
preview_pane plugin manages to
>> add extra frame, then some other plug might be able
remove it.
>>
>> if you disable ----
>>
$squirrelmail_plugin_hooks['options_folder_inside']['jump_to_folder']
=
>> 'jump_to_folder_options';
>> ----
>> in plugins/jump_to_folder/setup.php, user options are
removed.
>>
>> If you disable
>> ----
>> if (!isset($jump_to_folder_show_mailbox) ||
!$jump_to_folder_show_mailbox) return;
>> ----
>> in jump_to_folder_on_menu() function, selection box will
be always displayed.
>>
>> read doc/plugins.txt and try to use existing options
before you start changing
>> squirrelmail core scripts.
>>
I would also like to point out that the first version of
the frameless SM that the
CVS Branch is based was actually plugin based, with a few
minor changes to SM to
add the necessary hooks. So it can definitely be done via a
plugin with only
minor changes to the core. Just browsing through the patch,
it appears that it
just strips out everything to do with frames, instead of
allowing a user or admin
the option to have it one way or the other, or both.
Everyone has a way they
perfer, and they should be free to make that choice (as the
CVS Branch allows). I
personally don't mind frames, I like the fact that I don't
have to reload the
folder list everytime I click something on the page, but I
also respect other
peoples choices too, so thus my branch gives them the option
to "Have it your
way". As far as doing away with the folder list. Some
people might like it, and
again, some people may not, so an option should probably be
put in there for that
too. I personally can not live without my folder list. I
have 28 folders which
mail is filtered into, 12 of them are mailing lists. I
would not like to have to
browse to every single one of them inorder to see if I have
new messages, with the
folder list, I can just look and with a single glance see
that 2 of my lists have
new messages, and that I also have a message from my brother.
I guess it all boils down to one thing, choice. No one
would be happy with just
one way to do things, we have to cater to whims of everyone
else. Some people
bicker because we don't have noframes support, if we moved
to a complete noframes
version, people would bicker because they liked frames.
Some people would want to
remove the folder list, but once removed, people (including
me) would complain
because now checking their email becomes a chore. As a
community based group, we
have to strive to find a balance that everyone would be
happy with, and the
simplest way to do that is to allows the admin/users to
decide on their own
preference.
As it is now, I can not see this patch ever being accepted
into the SM core, it
offers no choice. Also the whole reason that the CVS branch
version is based on
Devel is because most people running 1.4.X run it because it
is the Stable branch.
The code has been tested, and retested to ensure that it is
not borked. I can't
see many of these people applying a major patch to a already
stable branch, that
kinda defeats the purpose. If the SM developers were to
consider this patch, it
means we would have to convert it to work with Devel, since
that is where it would
be applied (only bug fixes in Stable branch), and then we
would have to completely
rewrite it to give the users a choice.
I do thank you for your effort and the work you have put
into the patch. I am
sure that there are several people that will make use of it,
and will be very
happy with it. But as a developer, I have to look at the
whole picture, and I can
see that without lots of changes, this patch does not go in
the direction that I
believe that SM is heading. But don't let this discourage
your efforts, your work
and time is appreciated. I am hoping that we can combine
your work, with the work
that we have already put into the seperate CVS branch, and
meet on a common
ground. There is no reason to reinvent the wheel is alot of
the work has already
been done. All that really needs to be done, is add an
option in the CVS branch
to completely remove the folder list, plus a few other minor
right to left issues
(for Hebrew, ect..).
If anyone else has any comments on this, I would be gald
to hear them. I do feel
that it is about time we start work on the noframes support
in SM again. But then
we get into the whole templates debate also. Once templates
are implemented, the
noframes support will be done completely through them, so
should we even bother
with it now (and have to remove it all later), or focus on
templating SM, which is
a more pressing goal...
Jimmy
Logged In: NO
From mailing list:
>>>a) see jump_to_folder plugin. You can use it instead
modifying sm source
>>>>>> directly.
>>
>>>>
>>>> It won't fully solve the issue, since plugin won't be
>>>> i.e. when user is playing with settings. And if so, I'd
prefer not to rely on
>>>> external code if I need to modify source code anyway.
>
>>
>> plugin can be controled by end user, but controls can
also be disabled by admin.
>> SquirrelMail uses modular interface and selection box
that you want
>> to add can be implemented with existing squirrelmail
hooks. I suspect that you can
>> also remove frames with help of some hooks too. if
preview_pane plugin manages to
>> add extra frame, then some other plug might be able
remove it.
>>
>> if you disable ----
>>
$squirrelmail_plugin_hooks['options_folder_inside']['jump_to_folder']
=
>> 'jump_to_folder_options';
>> ----
>> in plugins/jump_to_folder/setup.php, user options are
removed.
>>
>> If you disable
>> ----
>> if (!isset($jump_to_folder_show_mailbox) ||
!$jump_to_folder_show_mailbox) return;
>> ----
>> in jump_to_folder_on_menu() function, selection box will
be always displayed.
>>
>> read doc/plugins.txt and try to use existing options
before you start changing
>> squirrelmail core scripts.
>>
I would also like to point out that the first version of
the frameless SM that the
CVS Branch is based was actually plugin based, with a few
minor changes to SM to
add the necessary hooks. So it can definitely be done via a
plugin with only
minor changes to the core. Just browsing through the patch,
it appears that it
just strips out everything to do with frames, instead of
allowing a user or admin
the option to have it one way or the other, or both.
Everyone has a way they
perfer, and they should be free to make that choice (as the
CVS Branch allows). I
personally don't mind frames, I like the fact that I don't
have to reload the
folder list everytime I click something on the page, but I
also respect other
peoples choices too, so thus my branch gives them the option
to "Have it your
way". As far as doing away with the folder list. Some
people might like it, and
again, some people may not, so an option should probably be
put in there for that
too. I personally can not live without my folder list. I
have 28 folders which
mail is filtered into, 12 of them are mailing lists. I
would not like to have to
browse to every single one of them inorder to see if I have
new messages, with the
folder list, I can just look and with a single glance see
that 2 of my lists have
new messages, and that I also have a message from my brother.
I guess it all boils down to one thing, choice. No one
would be happy with just
one way to do things, we have to cater to whims of everyone
else. Some people
bicker because we don't have noframes support, if we moved
to a complete noframes
version, people would bicker because they liked frames.
Some people would want to
remove the folder list, but once removed, people (including
me) would complain
because now checking their email becomes a chore. As a
community based group, we
have to strive to find a balance that everyone would be
happy with, and the
simplest way to do that is to allows the admin/users to
decide on their own
preference.
As it is now, I can not see this patch ever being accepted
into the SM core, it
offers no choice. Also the whole reason that the CVS branch
version is based on
Devel is because most people running 1.4.X run it because it
is the Stable branch.
The code has been tested, and retested to ensure that it is
not borked. I can't
see many of these people applying a major patch to a already
stable branch, that
kinda defeats the purpose. If the SM developers were to
consider this patch, it
means we would have to convert it to work with Devel, since
that is where it would
be applied (only bug fixes in Stable branch), and then we
would have to completely
rewrite it to give the users a choice.
I do thank you for your effort and the work you have put
into the patch. I am
sure that there are several people that will make use of it,
and will be very
happy with it. But as a developer, I have to look at the
whole picture, and I can
see that without lots of changes, this patch does not go in
the direction that I
believe that SM is heading. But don't let this discourage
your efforts, your work
and time is appreciated. I am hoping that we can combine
your work, with the work
that we have already put into the seperate CVS branch, and
meet on a common
ground. There is no reason to reinvent the wheel is alot of
the work has already
been done. All that really needs to be done, is add an
option in the CVS branch
to completely remove the folder list, plus a few other minor
right to left issues
(for Hebrew, ect..).
If anyone else has any comments on this, I would be gald
to hear them. I do feel
that it is about time we start work on the noframes support
in SM again. But then
we get into the whole templates debate also. Once templates
are implemented, the
noframes support will be done completely through them, so
should we even bother
with it now (and have to remove it all later), or focus on
templating SM, which is
a more pressing goal...
Jimmy
Logged In: NO
From mailing list:
>>>a) see jump_to_folder plugin. You can use it instead
modifying sm source
>>>>>> directly.
>>
>>>>
>>>> It won't fully solve the issue, since plugin won't be
>>>> i.e. when user is playing with settings. And if so, I'd
prefer not to rely on
>>>> external code if I need to modify source code anyway.
>
>>
>> plugin can be controled by end user, but controls can also
be disabled by admin.
>> SquirrelMail uses modular interface and selection box that
you want
>> to add can be implemented with existing squirrelmail
hooks. I suspect that you can
>> also remove frames with help of some hooks too. if
preview_pane plugin manages to
>> add extra frame, then some other plug might be able
remove it.
>>
>> if you disable ----
>> $squirrelmail_plugin_hooks['options_folder_inside']
['jump_to_folder'] =
>> 'jump_to_folder_options';
>> ----
>> in plugins/jump_to_folder/setup.php, user options are
removed.
>>
>> If you disable
>> ----
>> if (!isset($jump_to_folder_show_mailbox) || !
$jump_to_folder_show_mailbox) return;
>> ----
>> in jump_to_folder_on_menu() function, selection box will
be always displayed.
>>
>> read doc/plugins.txt and try to use existing options before
you start changing
>> squirrelmail core scripts.
>>
I would also like to point out that the first version of the
frameless SM that the
CVS Branch is based was actually plugin based, with a few
minor changes to SM to
add the necessary hooks. So it can definitely be done via a
plugin with only
minor changes to the core. Just browsing through the patch,
it appears that it
just strips out everything to do with frames, instead of
allowing a user or admin
the option to have it one way or the other, or both.
Everyone has a way they
perfer, and they should be free to make that choice (as the
CVS Branch allows). I
personally don't mind frames, I like the fact that I don't have
to reload the
folder list everytime I click something on the page, but I also
respect other
peoples choices too, so thus my branch gives them the
option to "Have it your
way". As far as doing away with the folder list. Some people
might like it, and
again, some people may not, so an option should probably be
put in there for that
too. I personally can not live without my folder list. I have
28 folders which
mail is filtered into, 12 of them are mailing lists. I would not
like to have to
browse to every single one of them inorder to see if I have
new messages, with the
folder list, I can just look and with a single glance see that 2
of my lists have
new messages, and that I also have a message from my
brother.
I guess it all boils down to one thing, choice. No one would
be happy with just
one way to do things, we have to cater to whims of
everyone else. Some people
bicker because we don't have noframes support, if we moved
to a complete noframes
version, people would bicker because they liked frames.
Some people would want to
remove the folder list, but once removed, people (including
me) would complain
because now checking their email becomes a chore. As a
community based group, we
have to strive to find a balance that everyone would be
happy with, and the
simplest way to do that is to allows the admin/users to
decide on their own
preference.
As it is now, I can not see this patch ever being accepted
into the SM core, it
offers no choice. Also the whole reason that the CVS branch
version is based on
Devel is because most people running 1.4.X run it because it
is the Stable branch.
The code has been tested, and retested to ensure that it is
not borked. I can't
see many of these people applying a major patch to a already
stable branch, that
kinda defeats the purpose. If the SM developers were to
consider this patch, it
means we would have to convert it to work with Devel, since
that is where it would
be applied (only bug fixes in Stable branch), and then we
would have to completely
rewrite it to give the users a choice.
I do thank you for your effort and the work you have put
into the patch. I am
sure that there are several people that will make use of it,
and will be very
happy with it. But as a developer, I have to look at the
whole picture, and I can
see that without lots of changes, this patch does not go in
the direction that I
believe that SM is heading. But don't let this discourage your
efforts, your work
and time is appreciated. I am hoping that we can combine
your work, with the work
that we have already put into the seperate CVS branch, and
meet on a common
ground. There is no reason to reinvent the wheel is alot of
the work has already
been done. All that really needs to be done, is add an option
in the CVS branch
to completely remove the folder list, plus a few other minor
right to left issues
(for Hebrew, ect..).
If anyone else has any comments on this, I would be gald to
hear them. I do feel
that it is about time we start work on the noframes support
in SM again. But then
we get into the whole templates debate also. Once
templates are implemented, the
noframes support will be done completely through them, so
should we even bother
with it now (and have to remove it all later), or focus on
templating SM, which is
a more pressing goal...
Jimmy
Logged In: YES
user_id=69131
As it seems some people read my intention wrong I need to
clear the whole picture a bit. I need to mentioned that all
those changes I've made to the SM code that this patch
contais was driven by my and only my needs (no frames, no
folder tree in general). I just simply wanted to shape SM to
make it as it looks when patched. Therefore it was never
intended to be a patch for general use, however rather small
range of my modifications and changes may make them useful
for other people (version I personally use is even more
tailored - the patch does not cover so specific
modifications). As one of the guys noted, I do not offer you
a choice. I was intentional - I had no time to contribute in
the "right way"{tm} with plugins and stuff. I just chopped
here, added there to get what I wanted. With no
configuration option to reverse my changes (unpatching does
not count ;) I would date to expected such code to be merged
with any branches. It shall be rather considered as
"contributed work" and such land in such section. Since
there's nothing like that on SF, it landed in patches. The
patch is made against stable branch (and only agains that)
as it does not offer "general revolution" to the code, so
when applied, it is not expected to violate SM stability. So
if one likes the way stable branch works *and* shares my
general needs then the patch is for him/her. All the others
will be happier with official code optionally enchanced with
proper set of plugins.
PS: I was never expected this would attract so much
attention ;) Thanks for all the notes and comments. Please
keep in mind this is rather mutation than evolution and keep
using it as such.